软g开发的D酷的现实告诉我们：(x)没有规则的Y件开发过E带来的只可能是无法预料的结果?br />
我们中的大多数项目管理h员在其个人简历中UL(fng)写到Q?#8220;拥有多年的丰富的目理l验”Q但在实际开发中Q?#8220;丰富?#8221;理l验变成了Y件开发h员可怕的梦魇。一ơ次的失败、一ơ次的返工，Ҏ(gu)谓的目理l验只不q是再一ơ的游戏?#8220;无间”Q十八层地狱Q。一ơ，在与不少目理者的交流中，大家UL(fng)提到的Y件变更带来的可怕媄响。但是正如完整的法律体制不能制止犯罪Q但没有完整的法律体制犯|会(x)更加猖獗一P频繁的Y件变更固然可怕，但是没有一个完整的目理对应机制Q我们无法相像项目最l会(x)是一个什么样子。此外还有一ơ，W者在求职Ӟ招聘公司的技术主（40-50岁左叻IQ向我吹嘘公司按CMM4的过E规则来q行软g的开发和理。殊不知Q我一问下面开发h员，她们在经历无数的加班后正在给已经完成的Y仉目添加Y件概要设计书Q这让我大吃一惊。如此这样Ş式主义的公司Q不呆也|?br /> 记得一个格a曄说过“人类最愚蠢的行为在于忘记常?#8221;。另外一句较为相仿的D则是“不知道历史的人必然会(x)重蹈覆辙”。作为项目管理来说亦为同L(fng)道理。很可惜Q我们中的大多数理者口口声?#8220;软g工程”Q工作时“用程序代替用户需?#8221;Q极h客的嘴脸。其l果必然如目前媒?#8220;E序员生存状?#8221;所aQ以开发h员在旉的牺牲ؓ(f)代h(hun)来换取项目的l束Q这是再为普遍不q的现象Q在此不再妄加评论?br /> 如何改善我们的Y件开发管理，一条便捷之道便?#8220;重常识Q尊重历史经验教?#8221;。在软g目理中，有许多的原则和经验可以供我们借鉴?nbsp;
一?计划原则
没有计划Q你无从知道什么时候控制和变更。制定一个详的计划Q以详细到开发h员可以理解的E度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不项目经理告诉组员需要做什么东西后扬长而去Q丝毫没有一个相关Q务（zdQ之间的说明。由于没有计划或是计划太_糙、不切实际，很多目1/3甚至1/2的时间花在返工上面。因划中遗漏了某一关键Q务，目有可能宣告p|。试想一下，制定一个周密合理的计划需要耗费q么多的旉吗？需要付出项目失败的代h(hun)吗？q有很多目理人员常常错误认ؓ(f)“变化比计划快”Q但实际的情冉|Q由于没有计划，你无法预和估量变化l你的项目所带来影响Q你所面(f)的将?x)是比面条还难以理清?#8220;h”状态。此外，对于开发h员来_(d)“目标导向QObjective OrientedQ?#8221;是充分调动其工作U极性的最x法，每一个Q务阶D늚成果能够员工的工作效率l持在一个较高的水^。因期目标L比远期目标来说更Ҏ(gu)看到和达到。ؓ(f)此，制定一个计划吧Q让它符合目标导向（通过各个具体d计划促ə目总计划的达成Q?nbsp;
二?Brooks原则
向一个已l滞后的目d人员Q可能会(x)佉K目更加滞后。因Z为新加入的员工来_(d)相关培训、环境熟(zhn)和人员之间的沟通通\的增加，qə目的工作效率急剧下跌。工作效率下降需要加班来q行弥补Q但加班造成的疲劳会(x)再次使工作效率降低。同时工作成本却不断的向上攀升。不q就目前来说Q项目管理h员丝毫不?x)理会(x)这一点，“人多力量?#8221;也许更能引h入胜。不项目管理h员抱怨到旉的急迫性，ȝ很多目内时间的急迫性来自于目理人员不假思烦和不Z常理的邀功表玎ͼ没有充分考虑的开发h员能力的多样性所致。ؓ(f)此，正规的企业不得不耗费大量的加班费用于加班人员的|_(d)同时亦要承担q反《劳动法》的潜在法律危险。现在一U万不得已的做法是，假设目开发h员之间的d的关联性不是太大的情况下，采取两班倒或是三班倒的Ҏ(gu)来保证时间的延箋性和相关开发h员的工作高效性?nbsp;
三?验收标准原则
我们在进行某Q务，往往?x)?f)以何U结果ؓ(f)宜而感到困惑。不求质量的开发h员往往凭据l验草草了事Q追求完的开发h员则在该Q务上耗费太多的精力，但此番耗费未必针对该项dQ因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的d需要一个什么样的结果，需要达C么样的质量标准。在很多情况下，你的zd?x)与期望l果背道而驰Q而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来_(d)只有制定好每个Q务的验收标准Q才能够严格把好每一个质量关、同时了解项目的q度情况?nbsp;
四?默认无效原则
你的目成员理解和赞成项目的范围、目标和你所制定的项目策略吗Q不项目管理h员认?#8220;沉默意味着同意”。实际上我们或多或少都会(x)陷入q样的一个思维误区。试想一下，你作员或目开发h员时的沉默完全代表你赞成你的领导的意见吗Q不见得Q这是{案。这一点在目沟通中极ؓ(f)重要Q项目管理者切不可为沉默认为是同意Q沉默在很大的程度上说明目开发h员还未弄清楚项目的范围、Q务和目标。ؓ(f)此项目管理者还需要同开发h员进行充分沟通，了解开发h员的x。在寚w目没有一个共同的一致的理解的前提下Q一个团队是不可能成功的?nbsp;
五?80-20原则
80-20原则在Y件开发和目理斚w有许?#8220;实例”。其一便是我们?0Q的目要求上耗费?0Q的旉。仔l分析一下，q些目要求分ؓ(f)必须的非必须的，因此我们是压~非必须的部分或是暂时将其放在一边不必太重视。Y仉目开发事实告诉我们，开发h员在非必ȝ目要求上耗费了太多的_֊Q用L(fng)需求变更的大部分出现在“最好有”q一部分Q实际上用户q不看重q些需求（即去除q些需求）Q而我们所做的Q往往是舍本求末?br />
80-20原则的另外一个实例是我们目中的20Q的人员担当?0Q的目dQ这栯在实际实施中一炚w不过分）。考虑到开发h员能力的多样性，聪明的项目管理h员决不会(x)采取d均分的愚蠢做法，因ؓ(f)ql论的观Ҏ(gu)看，互补l构比对{结构要更稳定一些。此外作为项目管理h员来_(d)了解属下员工的能力特点，其攑֜合适的位置上，?x)更有利于项目的利q行。很多管理h员常常抱怨属下能力问题，I其实质Q往往是这些项目管理h员未能发现开发h员潜能所在之处。她们看待问题往往?#8220;l验”q样的思维定势来做军_。导致的l果如系l论所aQ由?#8220;抱?#8221;的作用和反作用@环，l果是大安不欢而散?nbsp;
六?帕金原?/strong>
帕金原则原是用于反映政府部门机构臃肿，效率低下的代名词。不q它在Y件开发中一样适用。没有时限限制的话，工作可能无限延期。在软g开发中Q如果没有严格的旉限制Q开发h员往往比较懈怠。这是h的天性所军_的。千万不要指望奇q的发生―?#8220;所有员工的思想觉?zhn)异常崇?#8221;。作为项目管理者而言Q此时应充分考虑到员工的工作效率和项目变更带来的负面影响Q制定合理的目工期q动开发h员尽快完成?nbsp;
七、时间分配原?/strong>
在项目计划编制过E中Q我们常常将资源可用率（人、设备）{设|ؓ(f)100Q，D不知你曾想q，׃开发h员需要休息、吃饭、开?x)等Q根本不可能把所有的旉攑֜目开发工作上Q而且q还不考虑到开发h员的工作效率是否保持在一恒定水^上。所谓一?时工时制实际上是徒有虚名。由于项目管理h员的“无知”Q不开发h员被q拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中Q开发员工的旉利用率能够达?0Q就已经时很不错的了Q我个h比较們?0Q左叻I黄金分割点）。一个常用的l验是如果项目h员不懂技术的话，目旉可能是原计划Q该计划没有考虑到资源可用率Q的4/3Q?/3。如果项目h员不懂技术、管理h员不懂管理的话，q个数字可能?倍到3倍。现实就是这么严酗这很大范围?#8220;归功于项目管理h员。是的，我们的确没有必要责备开发h员，因ؓ(f)我们对资源可用率的判断完全违反常识?nbsp;
八、变化原?/strong>
也许有h问过你，在项目管理中唯一不变的东西是什么？我可以告诉你Q项目中唯一不变的就?#8220;变化”。在目中不考虑可能发生的变化是不可思议的。不q在面对目可能发生变化而带来的目风险Ӟ我们的项目管理h员往往?x)怀有逃避的态度。经学里大名鼎鼎的风险规避原则便是目理人员心理的有效描q。作为项目管理h员来_(d)应该?qing)早预测可能出现的风险，做好风险储备。虽焉险储备不能解x有的问题Q但?#8220;预防胜于ȝ”。可惜的是我们绝大多Ch没有q方面的意识Q否则医院的生意未必如此U火Q项目开发之途未必如此坎块?nbsp;
?ji)、作业标准原?/strong>
一个团队要完成目的开发需要有一定的章法。很可惜Q在国内目前仍然?#8220;作坊?#8221;ZQ高?#8220;我们W合国际CMM X规范QISO某某规范Q?#8221;的环境下Q未必有多少目团队注意到这一炏V我们曾l惊叹印度的高中生都能编E序Q而国内却非本U、硕士不收眼帘。究其原因，在于没有开发章法或是章法粗p，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多Ch~写E序随心所Ʋ的问题Q很可惜Q没有多项目管理h员有此意识，也没有多h愿意dq项基础d。业务Y件开发需要高的开发技巧吗Q不需要，那是故弄玄虚的开发h员的伎俩。Y件开发的在于其z性和规范性，不在于奇技淫y。因为缺乏作业标准，我们付出的代h客户的抱怨和无休止的q工。此外，对于那些以Ş式主意蒙人的目团队来说Q如果你实质如同你口头所说那P也许你就不会(x)是今天的q副狼狈相?nbsp;
十?复用和组l变革原则－解决目问题的未来之?/strong>
如何解决日益H出的项目工期、成本、质量等问题Q这是大多数目理者最为关心的问题。从实践来看加强复用的力度，建立目复用体系和实施组l变革是效果较好的途径之一。复用能够提高项目的生率，降低目风险。通过复用Q项目管理者能够快速的q入目问题定义之中Q减项目开发h员的工作量，从而尽可能的解决项目在旉、资源方面的q蝲问题。另外一条途径是实施项目团队的l织变革QMocQ，_目理机构、重新定义工作职责，制定柔性的目工作程Q改善项目开发h员的沟通状况，提高目人员的开发效率，努力营造一个良好的目开发环境。这h能从Ҏ(gu)上解决项目开发的U种手问题?nbsp;
l论Q作Z个项目管理者来_(d)了解和运用上q原则是不够的，若要深入的掌握项目管理知识和技巧，q必L入学?fn)项目管理（参看PMI《PMBOK》）、管理心理学、质量管理学、组l变革、系l论{方面的知识Qƈ在工作中不断的ȝ和实c唯有如此，我们的项目管理h员看自己个h历时方不?x)觉得脸U，才能在公怸?wi)立自己的管理权威性，同样也才?x)有一个良好的职业l理生的开端?br />
]]>
(2003.07.01) 来自Q计机世界
能力的提高往往不是从成功的l验中来Q而是从失败的教训中来?
在克莱斯勒汽车公司，一位项目经理把辞职信交l当时的CEO艄?#183;李，表示要对自己所领导目的失败负责。艾U卡拒绝了，他知道这位项目经理还
?x)在汽R行业l箋工作Q于是说Q?#8220;我不希望q?00万美元的学费替别的汽车公怺Q把教训C来，q是我们的胦富?#8221;q只是艾U卡带领克莱斯勒走出困境的一个小插曲Q却令h回味?
许多目l理不注意经验教训积累，即在项目运作中得头破血，也只是抱怨运气、环境或者团队配合不好，很少pȝ地分析ȝQ或者不知道怎样ȝQ以至于同样的问题不断出现?
可有可无的项目终l?
目ȝ王深刚进公司不久接CQ务，要求他尽快把目成本估算的准度抓一下。由于市场竞争激烈，公司不得不在没有_信息和数据的情况下，短时间内做出标书。这使过d个项目的q度大大延误Q成本失控，公司理层对各项目经理的信Q大打折扣?
王深查看了公司的目文g档案Q按ISO9000理来看q是比较规范的。他找来正处于项目收ND늚目l理李明Q请他写一个项目ȝ。要求项目组所有成员都参与ȝQ一周之后拿Z份完整的ȝ文g。李明的目比预定工期晚?个月Q成本比预算多出10万元Q但与大部分目相比Q这是做得不错的了?
颇王深意外的是Q两天后一份两늺的项目ȝ摆在他的办公桌上Q除了项目背景的介绍Q就是一些原则性的套话Q?#8220;加强合作、及(qing)时跟t?#8221;{等Q没有触?qing)Q何实质性问题。毫无疑问，公司的项目经理们觉得“ȝ”可有可无、无重，但是许多宝贵的经验就是这L(fng)白地丢掉了。也许，静下心来好好ȝ一下，我们可以学到很多东西?
?x)议主题Q抱?
不得Ԍ王深亲自召集李明的项目组开ȝ?x)。n雁发牢骚_(d)(x)“ȝ?x)不是已l开q了吗？我手上又接了一个电(sh)厂项目，马上要做详细设计了，q会(x)能不能不开Q?#8221;王深没有回答Q把李明写的报告递给赵雁Q问道：(x)“q些体会(x)Q你都清楚吗Q?#8221;赵雁扫了一|虽然有些不太明白Q但q是不以为然地说Q?#8220;q是目l理的事Q我们组员无所谓。况且，大部分项目根本就不写ȝ报告。想写也没有旉Q?#8221;
“q就是大家没长进的原因！” 王深不客气地_(d)“支10万元是怎样造成的？是选择分包商安装监控设备但又无法控刉料造成的！本想赚取材料差h(hun)Q却没考虑潜在的风险?#8221;王深接着_(d)(x)“我听说以前公司发生过cM的事情，不幸在我们的目上又发生了。要是ȝp栯草了事，下次q会(x)有！”
大家逐渐意识到ȝ的必要性，联想起以往工作Q纷U发表意见。话匣子一打开Qȝ?x)变成了一个控诉会(x)?
在项目ȝ?x)上Q这是常有的事。项目组把所受的委屈Q尤其是来自客户斚w的，l统发泄出来。但l论往往没有什么徏设性，大都?#8220;不要怿分包商的承诺、对客户的无CD求应拒绝”{没有指导意义的l论?
王深鼓励大家畅所Ʋ言Q他_(d)(x)“ȝ的意义在于判别结果和我们预想的是否一_(d)以便调整我们今后做计划的Ҏ(gu)Qؓ(f)以后的项目工作打基础。大家最好比较一下项目计划和实际执行的差距?#8221;
李明不好意思地_(d)(x)“我们的计划只更新q一ơ，大家基本不太用?#8221; 赵雁插话道：(x)“q是因ؓ(f)计划与实际太谱Q连我们自己都不怿它?#8221;
王深q没有责怪，他说Q?#8220;对于新的目Q我们的报h(hun)、h员安排、进度控制大都基于假设，q很正常。现在我们可以回q头来，逐一查当初的假设与现实情늚差距。下ơ同c项目，可以大大提高计划的准确率，其是在成本估算和报L(fng)略上Q也p提高中标率了?#8221; 在王q提醒下，大家的思\逐渐清晰Q原来带有发泄意味的各种意见也变得有些系l化了。n雁觉得大家的在新接的目中就用得上?
王深特别了风险识别意识。他_(d)(x)“q次在消防审批上的时间比预计的要长很多，影响了回ƾ，q应该加在风险列表中?#8221; 李明补充道：(x)“应该早更换늼供货商，我们一直希望他们能补上q度Q所以迟q没有启动备选供货商。虽然最后还是换了，但是耽误了两周的工期?#8221;
一份非怸错的ȝ报告出来了，过?0，特别_ֽ的是寚w险防范中启动应急计划的体会(x)以及(qing)工程量的估算部分?
成长的烦?
W者曾在一家外企工作，看到其完备的计划书、风险分析、文档模板，p地感Ҏ(gu)ȝ工作的艰辛。许多项目经理不是意识不到ȝ的重要性，而是疑虑所付出的劳动太多，是不是值得Q?
一位著名作家在参加亚洲作家W会(x)之后曾有q样的感惻I(x)我们代表团成员的论文动辄是lD、概q和势分析Q而少有像日本学者所做的~年双Ӏ作家生q证之类的基数据U篏。这或许是在中国文化某些领域我们的研I水q_而比外落后很多的原因吧?
目理水^的提高，M开目ȝq项基础工作。这是Q何教U书都无法替你做的。如果我们没有诸葛孔明的前瞻智慧Q那么项目ȝ上的亡羊补牢或许也能起到勤以补拙的效果?
我们往往只有在自q得头破血后才真切体?x)到别h的忠告是多么正确。在l历了无数的成长的烦g后，我们才能体会(x)“不听老haQ吃亏在眼前”q句老话的味道?
对于理目Q你q想重蹈覆辙吗？
]]>
原则1Q由_到l，从宏观到微观?br />
必须先从宏观上了解客户业务的全貌Q再逐步深入l节。因为对于客L(fng)业务而言Q我们是外行Q如果从业务l节着手，很容易迷失方向，失去对业务核心的把握。同时要认识刎ͼ对于一个外行而言Q我们对l节的深入也必定是有限的Q不要指望自p够无IL(fng)d的了解每一个细枝末节。一是不可能有无限的旉l你了解Q二是没有这个必要。因为未来的pȝ也不可能完全包办所有业务的l节Q还有很多事情是要靠客户企业中这些具有专业技能的人来做的?br />
原则2Q从不同层次的客户代表那里收集不同层ơ的需?br />
对于企业高层决策者，他会(x)l你描述一个系l的大的功能蓝图Q如使企业具有整体报仯力，能更好的服务于高端客P能支持企业的重大业务决策{；对于企业各理者，他会(x)l你讲述他这一层的理需求，如能更好的进行部门员工的业W考核、生成月度报表，更好的进行业务结等Q对于各U业务操作h员，他可能给你谈?qing)很多业务细节和操作l节……
在由上到下的逐访谈中，Ҏ(gu)来系l的描述׃一个大黑箱变成多个黑，再变成透明、明、详l的pȝ定义的过E?br />
客户业务调研和需求分析注定是一个不断细化的q程Q不要指望一ơ访?调研pI尽Q也不要指望一ơ开发过E就能得到完全满_h中期待的那套pȝ来。因Z实上很多需求是隐性的Q连用户都不清楚自己的需求。只有经q多ơ@环细化才可能把更多隐性的不断挖掘、暴露出来?br />
二、如何具体开展需求调研工作？
在RUP中定义需求工作流E的工作目的如下Q?br /> 1. 客户和其他涉?在系l的工作内容斚w达成q保持一_(d)
2. 使系l开发h员能够更清楚C解系l需求；
3. 定义pȝ边界Q限定）Q?br /> 4. 划P代的技术内Ҏ(gu)供基Q?br /> 5. Z开发系l所需成本和时间提供基Q?br /> 6. 定义pȝ的用L(fng)面，重点是用L(fng)需要和目标?br />
[涉众]Q英文stakeholder在RUP中的译Q在目理专著中往往译ؓ(f)“q系?#8221;Q指所有与目成|有直接间接利益关pȝ个h或团体。在软g目中，往往包括企业的投资者、各U管理者、系l用者、公司客P甚至包括企业的合作伙伴和竞争Ҏ(gu)?br />
首先要做好业务调研。要早把已l收集到的业务资料熟(zhn)v来，q在理解的基上提炼出问题列表Q制成调查问南业务调研的要求是一定要沉下去，深入l致的了解客L(fng)业务程Q而不是急着赶工完成自己的需求工件设计和业务模型的徏立。在了解各项业务程的同Ӟ与客户一同深入分析业务的实现逻辑Qƈ记录下有关的实现案例信息Q收集好、整理好、分析好有关的参考材料?br />
要把q代的思想贯穿于从业务调研、需求分析，乃至目实施的始l。所谓P代，是我们老老实实承认我们没有能力一ơ就把事情做到尽善尽。所以我们就先把一大部分有把握的地方做好，再在前面成功的基上不断做好剩余的部分Q最l就能无限接q于成功。设计编码过E是如此Q业务调研和需求分析也是如此?br />
企业pȝ的设计开发与软g产品的设计开发有一个最大的不同Q就是企业的需求肯定会(x)变化Q过d变、调研的时候会(x)变，pȝ实施后还?x)变。而我们要做的是去适应q种变化。事实上Q也正是因ؓ(f)我们采用的是面向对象的方法，才可能做到这一炏V因为面向对象的Ҏ(gu)认ؓ(f)Q对象的基本属性是客观的和不会(x)频繁变化的，而对象间的关pd是可能不断变化的。所以我们在业务调研和需求分析中也要认识到这一点，把不变的沉淀(wn)下来Q把可变的灵zL和变化的自L留l客戗?br />
各位都是做技术的Q在业务调研和需求分析中隑օ?x)不pȝ考虑一些技术实现的问题。值得的是Q需求与技术无兟뀂在业务调研的时候要忠实的进行记录，不要因ؓ(f)你个人对实现的疑虑而对用户需求进行（q早的）修改和裁减?br />
要善于争取客h各人员Q均是项目干pMhQRUP中称为涉众）的支持。只有得到未来系l用L(fng)充分参与Q项目才有可能最l取得成功。一套缺乏用户参与的pȝQ即使最后做出来也是注定没有人去用的?br />
一是要利用客户企业的组l关p，争取C层的支持Q由上到下进行调研配合；二是要会(x)在调研过E中为目标用h(wi)立有针对性的愿景Q让他认同愿景的同时d、积极的支持你的调研q程?br />
……
Q以下内容从略）
]]>
l常?x)遇到客戯Q这个东西急着要，要什么什么时候赶出来Q这个时候千万要拿得住，不能一呛_客户的，要考虑到风险，首先考虑q个能不能做Q做的话能不能完成，需不需要加班加炏V如果做h有难度，有没有替代方法，要真正了解客h要的是什么东西，评估一个合理的旉Q不能客戯多少旉多时间。如果情冉|较急，也要考虑是不是加班就一定完的成Q完成的质量又怎么栗同时不要想当然的认为只要加班就一定完的成Q要做好一个项目固然免不了加班Q不q要充分考虑到每个项目开发h员的情AQ适当的安排加班，如果今天需要加班，p惛_今天加班了明天就可能工作效率比较低，要权衡加班的得失和项目的q度QMQ就是加班要加的适当?/span>
从头到尾一个h可以贯穿整个目的不多，往往某个个项目做了一半，p抽到另外一个项目中Q新加入的hҎ(gu)个项目又不是很了解，q就需要花旉dQ如果项目周期比较长Q可能在前期先熟(zhn)上手，后面p帮上忙，如果是周期比较短的项目，必要性就不是很大了，与其花力气去带，不如把这个时间用到项目上?/span>
看项目是不是能够赚钱Qh力成本应该占?/span> 90% 的比重，所以和客户沟通的需求h员，应该要知道控刉目的生命周期Q什么算做项目上U，什么时候算做是后期l护阶段Q我想都马虎不得的。如果对客户的需求把握不准，或者对上线的时间没有一个明的概念Q那么这个项目就无法很好的控制时间成本，如果q_下来Q就很可能是一个亏本的试验品。在和客h触的q程中，p把握住一个原则，已经定的上U一般来说不能改动，除非客户的需求增加，一斚w要重新制定时间计划，一斚w要向客户q加相应的费用，q才能保证项目的剩余价倹{?/span>
协调好各斚w的关pd一个项目的持箋良好q行非常重要Q一斚w要不时把目的进度h员困隄各方面的情况向领导反馈，通过交流可以得到一些有用的信息Q同旉g解了你的工作Q你才能有一个坚强的后盾支持Q做什么不至于没有方向感。一斚w要处理和同事之间的关p，上班旉交流工作Q下班时间交感情，忙的时候让人加加班Q项目不紧张的时候就让h休息休息Q与Zؓ(f)善，与己为善Q大家心情好了，做v事情来效率才高?/span>
]]>