一个项目经理的经验总结.docx
《一个项目经理的经验总结.docx》由会员分享，可在线阅读，更多相关《一个项目经理的经验总结.docx（24页珍藏版）》请在冰点文库上搜索。
一个项目经理的经验总结
一个项目经理的经验总结
[收藏此页][打印]
作者：
globrand 2009-05-04
内容导航：
一个项目经理的经验总结
第1页：
一个项目经理的经验总结
文本Tag:
项目经理
【IT168技术文章】
本人做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。
以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。
项目开始阶段是一个最重要的阶段。
项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：
1.这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。
在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。
一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。
前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。
2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。
项目经理需要了解每个方面的人对这个项目的看法和期望是什么。
事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。
没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的；
3.基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。
首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。
领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？
是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；
4.在做整体项目计划前，还要大致计算一下你手上的资源。
首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。
对于这一点，你在做项目的风险控制计划的时候要充分考虑。
其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。
最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间；
5.现在是做项目说明书的时候了。
一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。
也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。
简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。
6.是到做总体计划的时间了吗？
不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。
因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。
如果一些问题不能得到解决的话，将发生什么样的后果。
如果资源不够，就要高层改变策略，增加对这个项目的投入。
甚至在条件许可的情况下，有些公司会放弃这个项目。
总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。
7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。
很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。
成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industryexpert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。
我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。
其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。
8.现在你要面对三群人：
你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。
既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。
很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。
下面的东西看起来无聊，其实还是很管用的：
第一个是规定信息的流动方式和介质，是推还是拉。
推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。
这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。
当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。
说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。
当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。
第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。
有理有时候为什么会说不清呢？
就是因为没有证据。
所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。
记住：
说了的就和没说一样，只有写下来大家签字后才算真正发生了的。
还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。
这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：
如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。
再比如不同事件的审批流程问题：
什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。
事先想得越周到，以后的工作就越主动。
9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。
这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。
首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。
项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。
需求定义的是做什么的问题，而这里说的是怎么做的问题。
这里要强调一点：
完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。
有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：
你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。
采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。
所有的结果最后用一个叫做甘特图的形式表现出来。
你做完这个表以后会惊奇地发现，甘特图上项目的崾奔浠嵩对堵浜笥谀愕募苹崾奔洌ㄇ┖贤娜擞涝恫换嵯日髑竽愕囊饧模５比唬Ч钅抗芾淼娜嘶岽筇甘裁碬BS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。
如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。
这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。
按照什么标准牺牲？
这个项目的战略！
我们在第三节提到过的战略。
我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。
所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？
战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。
好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。
进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。
当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。
项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。
和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：
“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”王局长：
“（*&$@@”。
和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。
和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。
与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。
一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。
这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。
你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。
所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。
会后，你自己写文档，做决定。
会议上大家的面子都被照顾了，自然实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。
组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。
在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：
美观大方、简洁明快】，这个要求我就不知道如何检查。
所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。
所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。
很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。
做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。
另外我插一句：
我是极其不主张到客户现场开发的。
尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。
我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。
项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。
他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。
接着，我们再谈谈最让人头痛的需求变更问题。
变更通常分为两种：
一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。
碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。
这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
1.确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；
2.和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？
3.（项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。
然后再让客户在上面签字。
见过医院给病人做手术以前让家人签的免责条款吗？
对，就学习那个，让大家都意识到任何的更改都有成本和代价。
恭喜恭喜！
你提升了！
欣喜若狂之后，你有些困惑，有些心虚：
“我能胜任吗？
”压力和挑战让你有些招架不住。
你可能是一名出色的专业人士，此前一直作为团队的成员而工作，但从来没有领导过一个团队。
你发现突然之间你要负责一个时间紧迫的项目，并要为十几个甚至几十个人扮演协调员的角色，而你几乎对此毫无准备。
对许多人来说，从团队的普通成员到担任团队领导是一个重大而艰难的转折。
它可以加速你的上升势头，也可以毁掉你的整个职业生涯。
人们往往是在经历挫折之后，才最终领会“领导”的涵义。
作为团队的领导，你必须掌握五条：
管理过程；树立威信；边学习边领导；领导每个人；适度民主。
1.关键是管理过程
首先要学会如何授权，都亲自做就不是经理。
对许多人来说，获得晋升后的第一反应是承担更多的工作。
在他们心目中，只有这样才能确保完成从未承担过的重要任务。
这些人常常用“一手包办”代替了思考。
对于他们来说，最大的挑战就是改变工作方式。
因为你一向是亲自动手的，所以问题解决起来并不困难。
但你必须学会让别人帮你解决问题。
康新德就落入了亲力亲为的陷阱。
他在生产部做了两年，最近被提升为项目经理，领导一个11人的团队。
起初，每当他看到小组的进度落后了，就会挽起袖子亲自上阵。
可是他做得越多，手下的人就做得越少，也越来越缺乏积极性。
他们会把工间操的时间拖得很长，对显而易见的问题也要等待特别的指示。
康本以为自己是在帮助组员们，但组员们则认为这是在暗示他们干活太慢：
“瞧，我比你们干得快。
”康很快意识到自己的工作不是替整个小组完成任务，而是提供方向、动力和工具。
实际上每一位领导人最终都会认识到这一点。
这是一个简单的教训，但很容易被忽略：
能授权的事情就不要亲自做。
要关注管理过程，而不是内容。
美国巴布森学院的安•唐纳伦教授总结说：
“要管理过程，而不是内容。
领导的真正工作是掌握日程和信息的流动。
但太多的人试图控制细节，他们把自己当成‘工匠’，这只能使下属承担越来越少的责任。
”
既管理过程又管理内容会大大降低团队的积极性。
灵感公司的布莱恩•阿舍原来是一名程序员，最近升任项目经理，负责公司拥有900万用户的旗舰产品——个人财务软件。
“作为项目经理，我的职责是把产品开发出来、发布出去、定位和找到目标客户。
最大的挑战是在所有的事情中找到优先次序：
哪些是可以不做的？
哪些是可以授权让下面的人去做的？
哪些是可以交给上级去做的？
哪些是今天必须作出决定的？
”
阿舍运用了工程学的思维模式来应对这一挑战。
他找出对于项目成功至为关键的三个因素，每天早晨审阅自己当天的工作清单时，他会判断哪些事情有助于累积成功因素，哪些没有助益。
他自己做有益的那些工作，把其余的事情在15个工程师中进行分派。
“我在无关痛痒的事情上浪费了大量时间。
我不得不问自己这样的问题：
‘怎样才能既为那些需要帮助的人提供帮助，又不必亲自为此花费时间？
’”
2.威信是领导效能之本
没有主见，不能坚持自我当不好领导。
当上领导是职场生涯的一个重要变化。
但你不能前后判若两人。
相当一部分新领导急于完成从“团体中的成员”到总司令的转变。
这是错误的。
阿舍说：
“不要一当上领导就架子十足。
轻松一点。
人们希望看到原来的你，与大家有人情的联系，使人们感觉工作是愉快的。
你不能忘了你是谁。
”
这说起来容易做起来难。
南希•陶乐刚刚接任新岗位时，下属们对她很不以为然。
这个小组已经在一起工作了六个月的时间。
人们非常喜欢以前那位经理的工作方式，对此人的离任颇为遗憾。
她的前任与组员的交流做得很好，对日常琐事管得很细。
但陶乐不是这样。
她只抓大事。
前任善于表达和说理，而她认为自己比较腼腆。
“大家确实喜欢她，而不了解我。
”她回忆说，“团队的成员不会自动尊重你的新头衔，所以我得确立自己的做事方式，让他们了解我是如何工作的，通过具体事例显示自己的能力。
”她抓了前任忽略的两件大事——理顺和一位关键供应商的关系，为团队的新产品设想更多潜在的功能——细节问题则让组员们放手去做。
陶乐的目标很清楚：
“把产品做出来。
”她选择用自己的方式指导这一过程，最终领导团队克服了前进中的困难。
有不当之处要适度修正。
这并不等于说新领导不需要修正自己的工作方式。
阿舍接手新项目不久，一名下属找他单独谈话，而且是有备而来。
她拿出了一份列有前任经理优缺点的清单，足足有两页纸，表示希望阿舍成为什么样的领导人。
阿舍采纳了建议。
“作为经理，我发现有些事情做起来很容易，可以让她感到愉快而有益。
”
但改变是有限度的。
“前一位经理事事迎合她并不意味着我也会这样。
那样我就不是我自己了。
”
3.边学习边领导是成功之路
把握角色，外行就能领导内行。
有些时候，你的新职务把你放到了不熟悉的领域。
你手下的人对部门的业务比你更加内行。
如何避免外行领导内行带来的尴尬呢？
在这样的时候，即便从行政序列上讲团队成员需要你的指导，你也必须向他们学习专业知识。
波音公司的布鲁斯•莫拉维克当了七年的制造工程师，拥有出色的技术。
但当他被提拔为757改型项目的经理时，他认识到作为对某一领域知之甚少的外行，他必须赢得内行人的尊重。
这个项目要加长机身，他也必须扩展自己的技能，并在这同时领导别人。
“你得为新的角色建立威信，同时还得丰富自身的知识，”他说，“如果你看人看得很准，就可以找一些你不熟悉领域里的专家，并开始依赖他们获取信息。
”
在需要边学习，边领导的时候，如何达到一种平衡呢？
莫拉维克说：
“不要假充内行，那样注定要失败。
我跟所有的下属讲，我们的角色是不同的：
我的工作是整合资源，他们是专家。
”（相关报道参见本期34页“外行管内行，有何不可”一文）
没有行家就大家共同创业。
柯里•沙平被任命为一家天然气公司的客户开发小组经理时，必须实现个人技能的新跨越。
他在油田作业部工作过三年，对自己擅长的领域得心应手、胜任愉快。
但现在他必须转入营销和流程设计。
而且他面临一个更棘手的基本问题：
他的小组在公司中没有先例可循，他和他的组员都不知道如何开展工作。
他的解决之道是：
“大家一起想办法。
”
“接到任命时我的脑子里乱极了。
我甚至不知道这个小组是干什么的。
我向组员们介绍我自己，想看看我是否能起点作用，以及能起什么样的作用。
”沙平的组员们和他一样心存疑虑。
为了开创客户服务业务，这些人已经在一起工作了四个月，但一直没有一位正式的领导。
沙平的自我介绍很快引来了小组成员对他的一场集体面试。
“他们反过来向我提了一堆问题。
‘你认为这个小组应该怎么搞？
我们应该怎样设计流程？
你打算怎么支持我们？
’”
那么新领导是如何回答这些问题的呢？
他说：
“我承认我也不太清楚做什么。
我打算先熟悉一下他们的工作，了解一下他们希望我做些什么，公司希望我们做些什么。
当他们发现我没有预设的条条框框时，就说：
‘那咱们一起干吧！
’”
这是几年以前的事情了。
现在，沙平仍不认为自己成了行家。
“如果你问我：
‘你能替你的小组完成工作吗？
’我会说不能。
但是，如果你问他们：
‘你们能做柯里为小组所做的事情吗？
’我希望他们的回答也是不能。
”
4.领导单位就是领导每个人
领导每个人，而不是领导团队。
团队领导并不领导团队，而是领导组成团队的个人。
这句话言简意深。
成员各有各的优点、缺点，偏好，盲区和痛处。
专家称，要想领导一个团队，必须首先学会领导团队中的每一个人。
领导是一项一对一的活动。
心理学家和团队专家哈维•罗宾斯说：
“团队领导最重要的技巧就是要学会与各式各样的人打交道。
你必须了解人们希望你怎样对待他们，然后才能让他们跟随你。
”
对于波音公司的布鲁斯•莫拉维克来说，带领300人造一架飞机，很难实施一对一的领导。
“我手下95%的人都是从其他部门领薪水的，我所能做的只是对他们施加影响。
”
他怎样对这几百号人施加影响呢？
“我的工作方式比较随意，我只是四处走走，问问他们进展如何。
如果你不了解别人的角色和难处，就很容易苛责别人。
大多数人都希望把工作做好。
你得让他们知道你是来帮助他们的，而不只是站在那里发号施令的。
”
为了凝聚人心，莫拉维克反复向团队的每一个成员灌输一个基本的信条：
“我们都是来造飞机的。
如果飞机能讲话，它希望我们怎么做？
我们又该怎样实现它的心愿呢？
”
不过他也注意对小组成员区别对待。
最近，一位工程师拖拖拉拉不肯签署一份授权书。
莫拉维克提出如果他能在那天把文件签字生效，就可以得到一打面包圈。
下午4点钟的时候，授权书放到了莫拉维克的座位上。
第二天早晨，这位工程师得到了一打面包圈。
“当时他的眼神实在太有趣了，”莫拉维克回忆道，“就好像在说：
啊？
你真给面包圈啊？
”
要认识到忽视个人要求的恶果
柯里•沙平付出了沉重的代价才懂得不能忽视个人要求的道理。
他的小组组建两年以后，虽然小组取得了出色的成绩，但有人开始离职。
其中一人对小组的工作方式不满。
她是一个“干净利落”派，不能忍受项目中一些长久悬而未决的事情。
沙平没有满足她的要求。
另一个人因为薪酬歧视而辞职。
“我对这件事情未予理睬，因为当时我觉得自己对此无能为力。
但是她觉得不公平而最终选择了离开。
我没有看到小组成员的个人需要。
现在看来，问题不解决只会恶化，我本应该及早做点什么。
”
升级会员 