做项目就得这么干漫画项目管理实战.docx
《做项目就得这么干漫画项目管理实战.docx》由会员分享，可在线阅读，更多相关《做项目就得这么干漫画项目管理实战.docx（24页珍藏版）》请在冰豆网上搜索。
做项目就得这么干漫画项目管理实战
项目管理
∙前言
o社会的浮躁与泛项目化导致“项目管理”成为时髦概念，其结果必将降低项目管理的真正价值和生命力。
o项目经理并不是老板，而是属于弱势管理者，实际权力比较小，但要对项目的成败负责，所以更需要软性技能，通过沟通解决项目中的各种实际问题。
∙第一篇、项目管理越来越成为组织发展的手段
∙实践是最好的老师，但智者还能从其他的地方有所收获。
Experienceisadearteacher，butfoolswilllearnatnoother.
o1.1、什么是项目管理
o我们把“创造独特的产品、服务或成果而进行的临时性工作”称为项目。
▪项目本质上属于非重复性工作，往往使用有限的资源、在有限的时间内为特定的干系人完成特定目标而开展工作，而且这些工作基本都是一次性的。
▪非重复性的项目工作有两个主要特点：
临时性和独特性。
▪我们把“通过开展持续的活动来生产同样的产品或提供重复的服务的工作”称为运营。
▪项目与运营的主要区别在于，运营是持续性的、重复的；项目是临时性的、独特的。
▪项目需要项目管理，运营则需要业务流程管理或运营管理。
▪项目实现组织的持续发展，运营保证组织的持续稳定。
▪项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。
可以根据其逻辑关系，把这项目过程归类成五大过程组：
启动、规划、执行、监控和收尾。
o1.2、做不完的项目
▪项目是企业的成长发动机，更是每个人、特别是管理人员业绩的主要来源。
o1.3、项目管理本质上是一种框架管理
▪项目与运营的管理方式是不同的。
▪独特性工作与重复性工作的管理方式
∙
▪运营管理的本质是流程管理
▪每个项目都有其独特性，其创造的产品、服务或成果可能存在不确定性，项目团队所面临的项目任务是新的（甚至是全新的）。
要么时间要求很紧急、要么成本控制很苛刻、要么需要质量第一，每个干系人对其有不同期望，而且时常受到事业环境因素的制约。
▪试图给项目建立所谓的流程是危险的，时常导致“一管就死，一放就乱”的困境，这也是国内普遍存在的问题。
理解针对项目独特性而建立的“框架管理”本质，对项目管理的成功具有重要的实践意义
o1.4、项目管理的价值在于沿着正确方向获得正确结果
▪要取得成功，首先要选择正确的方向，然后再使用正确的方法。
▪选择正确方向属于战略管理，使用正确方法属于项目管理；战略管理在前，项目管理在后。
从这种意义上讲，战略管理比项目管理的层次更高。
▪战争中，有了正确的路线方针后，干部是决定性因素。
∙第二篇、成功项目源自组织和高层的支持
∙在决定员工绩效的因素中，有94%以上是他们自己所不能决定的。
Amongthefactorsthatdeterminetheperformanceofthestaff，therearemorethan94%ofthemcannotbedeterminedbythemselves.
o2.1什么样的项目算是成功的
▪验收通过是项目成功与否的基本条件
▪项目成功标准是随时代变迁而逐渐演化的
∙1、帝王早期，只要把规定的工作干好就意味着项目成功，并没有明确的时间和成本限制，秦始皇陵和金字塔就是例证。
∙2、时代变迁，项目的成功标准逐步演变为在规定时间内把工作做完。
钱用完了可以再申请，但是必须按时完工，隋朝的京杭大运河是一个典型代表。
∙3、在现代，普遍接受的项目成功标准是三重约束：
范围、成本、时间（另一种说法是质量、成本、时间。
）。
∙4、现在，项目不仅要在规定的范围、时间和费用内把事情做完，还要符合质量要求并使干系人满意。
当然，时间、费用、质量也是项目干系人的需求，因而可以简单地认为：
项目成功就是让项目的干系人满意。
▪关于项目成功的判断标准几乎都是主观的
∙项目干系人的看法、环境及各种期望都会对失败的判断产生影响。
在客户公司中，与项目团队一起工作的人可能认为项目是成功的，但客户的老板却未必这么认为。
▪在项目早期，制定出各干系人一致认可的成功标准是多么重要。
o2.2真正成功的项目是可以复制的
▪在国人的文化里，某种程度都有试图绕开程序的想法（总有人试图拥有特权），以至于不喜欢按照程序做事。
▪程序的价值在于可复制性（或说可控性）
∙靠人完成工作往往有较大风险，因为人是容易出问题的。
对组织而言，经验再丰富的人其价值也是有限的。
而能把经验总结转化为程序，使得后来人可以重复实现，这就非常有价值。
▪成功的项目应该是可以为组织或后续项目提供可复制的方法、技术或经验。
o2.3中国特色项目之“项目过程”
▪项目是一种临时性、独特性的任务，对任何一个项目的管理在某种程度上都是风险管理，不做有效的可行性论证，没有明确目标和有效计划使得项目过程完全不受控，甚至走到哪儿算哪儿。
有人将这种项目过程冠以中国特色的项目管理！
▪中国的问题只要找到了“国情”“特色”，大家就都没有责任了！
▪方法论背后应该是一部血泪史—其中不少弥足珍贵的经验或原则是人们在诸多项目失败的痛苦中总结出来的。
有人说，方法论来自失败和恐惧，是诸多项目实施的先驱们痛定思痛的结果，是实施专家经过理论研究并在总结了无数案例和成功经验的基础上提炼而成的。
▪从“摸着石头过河”到方法论是历史演进的必然，也是项目实施从高风险、不确定态演进到低风险、稳定态的保障。
领先一步叫先进，领先三步叫先烈。
大约先烈们在做事情的时候是没有方法论的，他们只能靠“试错”，所以大都失败、成为先烈。
▪后人只有汲取先烈的经验教训，才能降低失败的风险，提高实施的成功率，有机会成为先进。
▪到今天实施项目还蛮干的人，不仅对自己不负责任，而且着实对不起以前的先烈！
o2.4中国特色项目之“六拍”
▪第一拍——拍脑袋：
领导立项
∙经常有些领导有了做一个项目的想法后，不是组织相关人员严格论证是否可行，而是自己觉得可行就上马。
▪第二拍——拍肩膀：
任命项目经理
∙启动会议上，为了鼓舞士气、调动项目经理的积极性，领导拍着项目经理的肩膀进行激励：
“好好干，前途无量。
”
▪第三拍——拍胸脯：
项目经理向领导承诺
∙受到领导激励的项目组成员为了让领导放心，也会有所表示—拍胸脯，而且“牛人”们往往还会表决心：
“选择我，没错的！
”“放心吧，包在我身上！
”
▪第四拍——拍桌子：
项目遇到问题时相互攻击
∙项目进行一段时间后，运转情况远达不到预期，而且不知不觉中陷入了“墨菲定律”的陷阱，领导忽然发现项目进展情况与预期相去甚远。
在领导们的压力之下，团队成员间的冲突开始出现，推卸责任、抓凶手、互相攻击——拍桌子！
瞪眼睛！
这成了项目中一些脾气暴躁的团队成员束手无策时或着急上火时常做的事。
▪第五拍——拍屁股：
项目经理干不下去走人
∙团队的震荡冲突，项目的种种问题，使项目经理越来越难以驾驭。
拍屁股——“不给支持、只要结果，现在项目做不下去了，就知道训我？
我还不干了呢！
走人！
”
▪第六拍——拍大腿：
领导后悔
∙项目结果令人大失所望，领导开始后悔项目开始时的决策和冲动：
为什么上这个项目？
为什么选择项目经理不慎重？
为什么项目过程不认真策划？
……大家都拍大腿——痛心不已，却又无可奈何：
“唉，早知如此，当初就应该……”
o2.5中国特色项目之“三边”
▪1．边设计
∙项目开始时，项目经理和他的团队不清楚项目目标，也不知道项目具体该如何做。
范围不清、目标不明，盲目、朦胧地凭感觉来做，边走、边设计，“摸着石头过河”成了一种习惯。
▪2．边实施
∙实施过程就像傻子和面，面多了加水，水多了加面，最后把人都糊到面团里了。
我经常讲哥伦布式的管理，项目实施也有哥伦布式的项目。
整个过程是一种布朗运动，完全是一个无序的混沌态。
▪3．边修改（边返工）
∙所谓计划不如变化快，项目环境实在多变，发生很多“始料未及”的事情。
情况变了，随需应变，改呗。
改来改去改成什么样子谁也不知道，反正最终的结果是什么样大家都不清楚，就顺其自然吧。
▪“三边”项目的结果是未知的，全凭运气，运气好就成功了。
o2.6中国特色项目之“四没”
▪1．没问题：
项目开始时
∙项目开始时，乐观主义情绪充斥在组织上下，每个人都对项目的未来充满想象，风险意识全无。
即便项目有可行性研究，也常是“为可行而进行研究”——研究到最后都是可行的！
此时，即便有人提出疑问，也常被当做异类，没有人听进去。
▪2．没关系：
项目实施中
∙项目实施过程中，时不时会遇到一些客户需求变更，而客户往往又表达不够清晰，技术牛人们常在内心里有“他不懂”的想法，认为按照自己的想法就够了，对所谓的“小问题”不以为然——没关系，为项目失败埋下了祸根，他们往往不记得“项目成功取决于干系人的感知”。
▪3．没办法：
项目失败了
∙不出所料的项目结果终于如期而至，进度超期、成本超支、挫折感弥漫！
……“客户根本就不懂，这种客户不是我们服务的对象”“中国特色呗”……
▪4．没资源：
项目总结时
∙职能经理：
“市场部不知道客户的关键干系人是谁，根本就不知道客户的真正需求是什么？
”市场经理：
“我已经拿到了订单，做好项目是项目经理和你们职能部门的责任。
客户对我们的技术水平和服务态度很不满意，你们把我好不容易拿下的客户得罪了！
”项目经理：
“公司实施这种项目需要大家共同努力，市场部门没能搞定客户，各职能部门资源不能保证，根本就是先天不足——没资源。
”
o2.7项目是基于业务的面向干系人的过程
▪很多信息化项目的失败是先天注定的！
▪信息化项目绝非简单项目，公司高层、各部门部长、公司所有员工都是项目的重要干系人，都对项目有自己的期望，不认真考虑所有干系人的需求必然会带来负面影响。
▪信息化项目涉及公司的流程改进和管理变革，异常复杂；换言之，信息化项目是一个面对人的过程，而不是一个简单的技术工作。
这也是很少见到成功的信息化项目的真正原因。
▪ERP项目涉及公司各部门的流程改造和管理调整，需要各部门配合。
▪实践表明，清楚识别项目干系人并让他们承担起对项目的责任绝非易事。
有时一个项目进行了很长时间，但项目组未必知道项目的真正客户是谁，常犯的错误是仅将项目成果的直接使用者作为客户。
▪技术背景的项目经理经常犯的错误就是喜欢面对感觉容易沟通的人，但是问题是这些“容易沟通的人”未必是最重要的干系人。
一个研发类项目，项目经理和客户的研发部技术负责人沟通需求，就是一个严重的问题。
多数情况下，需求并不来自技术部门，而是来自业务部门。
▪作为项目经理，一定要能够把自己提升到业务的高度，有能力和业务层面的人员直接进行沟通。
o2.8大象是不会和老鼠沟通的
▪项目发起人通常是处于组织的高层管理人员。
除了正常的工作外，当项目需要时，必须能够提供必要的帮助。
▪项目发起人实际上像项目经理的“大哥”或建议者。
项目发起人应该帮助项目经理解决那些项目经理自己不能解决的问题。
▪请记住：
应该让合适的人担任发起人和项目经理，大象是不会和老鼠沟通的。
o2.9面对发起人与上级的不一致
▪项目发起人被认为是影响项目决策的关键干系人。
但是，发起人通常拥有既定利益，如果项目经理认为发起人做出了一个错误的决定，他该怎么办？
项目经理是否要走上上诉道路？
▪当发起人与高级管理层间的矛盾（尤其是政治因素）影响到项目时，项目经理又当如何？
通常，对于高级管理层之间的冲突项目经理没有能力解决这个问题，也轮不到他来解决。
更严重的是，发起人与高层管理者之间的利益，比项目经理与上述二者之间的利益关系更密切。
▪领导层内部经常出现不同的声音，而且，不同的声音并不能通过正常的程序取得一致。
▪在管理学上，“政治”至少是中性而不是负面的。
如果你希望别人支持你，你必须先对对方有充分的理解，这个就是“政治敏感”，也是最为典型的“中国特色”的技能。
▪面对高层管理者之间的不一致类问题，我建议的原则主要有两个：
∙关注利益而非立场；不参与政治，但是必要时可以利用政治。
▪如果项目经理仍然在现有组织中生存和发展，可以采用如下办法：
∙1．没有永远的立场，只有永远的利益
o尝试去探讨“真实动机”，而不是表面的“立场”，真实动机往往是和利益直接相关的。
有时候尝试给一些试探性的建议，有助于理解对方的真实想法。
∙2．提升“政治敏感”性
o遇到问题时，尽力考虑周全，在处理工作之前，尽可能通过面对面的非正式沟通（如午餐、运动）方式了解领导之间的意见。
∙3．从厚黑学角度（我不喜欢厚黑学）理解
o如果一定要站队，我建议站在直属领导一边，否则会让自己陷于“时刻郁闷中”，因为顶头上司与自己待在一起的时间更长。
除非你可以明确地判断出顶头上司“待不久了”。
∙4．多请示，多汇报，尽人事，听天命
o无奈的体现，这是弱者经常使用的“阿Q方法”。
o2.10跑偏的“项目经理负责制”
o在决定员工绩效的因素中，有94%以上是他们自己所不能决定的。
▪1．项目经理应承担的责任有限的
∙项目经理之所以被称为“项目经理”，是因为有了项目才有这个职位，没有项目这个职位自然就消失了。
“先有项目，再有项目经理”是基本的时间顺序。
多数情况下，决定项目该不该干的人是企业高管，项目经理只是完成项目，他们不是项目的决策者。
∙“以无比高的效率完成了一件不该干的事情”是最糟糕的问题之一。
“做正确的项目”往往比“将项目做正确”对企业来说更基本、更重要。
对一个项目正确与否的判断，责任不应该由项目经理来承担，他们也担不起这个责任。
▪2．项目经理的权限和可用资源是有限的
∙临时性的项目经理和稳定的职能经理之间常常存在资源使用上的冲突。
项目经理当然希望资源越多越好，而部门经理则希望项目资源消耗得越少越好。
因此，不仅在项目决策上项目经理说了不算，即使在做项目计划时，项目经理也时常说了不算。
他们需要去和职能经理商量，常见现象是项目经理需要的是“贤人”，但职能部门提供的是“闲人”。
职能经理和项目经理常常为了抢夺项目资源而起纠纷。
▪3．项目成功与否更依赖于项目治理
∙尽管项目管理的重要性已被越来越多的人认识，但多数人仍认为项目管理是项目经理的事，而没有意识到高级管理层和项目发起人的项目管理责任。
要想项目取得成功，不仅需要胜任的项目经理去完成项目管理，还需要胜任的组织高管去对项目进行有效治理。
▪项目治理的成果是项目成功与否的战略方向，而项目经理们只是按照这一方向具体实施项目的人。
o2.11可行性研究的是“为可行进行的研究”？
▪可行性分析失效的原因很多，我将其归为四点：
∙1．摆“花架子”、玩“两张皮”，为领导而论证
o可行性论证前，领导已经有了想法和主意，工作只是履行一个程序而已。
我将这种论证称为“为领导论证”。
∙2．倾向性意见导致判断上的自负
o众所周知，人们在大多数概率判断时都会自负。
也就是说，他们认为自己知道的比实际知道的要多。
研究证据表明，人们在困难问题上会过于自信，而在简单问题上则会缺乏自信。
∙3．论证对象的选择天生缺陷，论证内容不足
o项目的可行性研究一般注重技术经济分析，而忽视了项目风险的主要来源—管理，忽略了管理可行性研究。
管理风险是项目最大的风险来源，特别是对来自企业外部的其他干系人的管理更是如此。
∙4．对论证结论不负责任，专家“家奴化”
o管理和决策的系统设计缺陷，对评估结论不负责任或责任很小，从事可行性评估的“专家”要么迎合领导意图，要么是“伪专家”。
这些都促使专家们不负责任地说昏话、狂话甚至神话。
现在很多政治、经济问题的出现，与一些经济学家、法学家、社会学家说话不担责任不无干系。
∙第三篇、需求管理是项目管理的真正难点
∙不变只是愿望，变化才是永恒。
Thereisnothinginthisworldconstantbutinconstancy.
o3.1好的需求和目标应该符合SMART法则
▪需求和目标管理是项目经理变被动工作为主动工作的好手段，好的需求管控和目标确认不但有利于团队高效工作，也为项目绩效考核制定标准；没有可验证目标的项目注定失败。
制定目标看似一件简单的事情，实则不然。
▪SMART法则
∙Specific：
目标是用具体语言清楚地表达的；
∙Measurable：
目标是可以验证和测量的；
∙Attai门able：
目标是通过努力可以实现的；
∙Relevant：
目标是与工作有相关性的；
∙Time-based：
目标是有时间限制的。
▪常见的不明确的目标如下:
∙客户满意（什么是满意）；
∙快速响应（多长时间算快速）；
∙稳定运行（稳定指哪些指标）；
∙有效控制（如何算有效）
o3.2一个“泛项目”的诞生
▪“范项目”是不能预先将目标、范围等清晰定义而只能大致明确的项目。
▪新产品研发（如抗埃博拉病毒药物的研制）常是“泛项目”，人们无法预知该项目将遇到何种技术难题、它们究竟需要多长时间才能攻克。
▪作为项目经理，尤其是新技术行业的项目经理，都会遇到“客户逼”“上司压”“牛人顶”的局面。
这是任何技术手段都无法解决的矛盾。
o3.3需求的关键在于挖掘背后的业务
▪项目经理要有非常好的沟通能力，但沟通能力并不仅表现为滔滔不绝地说，很多时候，静下心来听是更重要的技巧。
▪项目经理需要的是耐心、技巧和深层次的沟通，搞清楚客户和干系人的真实想法
▪再次提醒项目经理，你是业务层面的管理者，项目是基于业务导向的。
o3.4展示你的样板房
▪在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。
∙客户买房子之前是先要看看样板房和模型的，什么都看不到这房子你敢买吗？
除非你不是自己住！
▪在概要设计阶段所衍生出来的需求工作量是之前的5～10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。
▪在中国实施软件项目，必须以咨询方式展开：
要推出自己的方案，而不能完全按照客户提的需求做项目。
▪要做好项目，实施者必须有很好的业务建模能力，快速地给客户展示合理的软件Demo。
多年的经验告诉我，对于软件项目，一定要给用户看到“样板房”——软件Demo，才算需求调研结束！
o3.5忘记项目目标是技术型项目经理面前的一堵墙
▪时刻铭记项目目标是项目管理很重要的一个思维，项目所有的活动都围绕这个展开。
▪随着项目的逐步开展，尤其是复杂项目：
人多、事多、周期长，很多项目经理会逐渐因为个人喜好而忘记了项目的大目标，比较典型的表现有以下几点。
∙技术出身的项目经理会沉迷于技术细节，花大量时间在学习新技术或者一头闷在解决技术难题上；
∙脾气火爆的项目经理会因为很多小事情大发脾气，把团队搞得乌烟瘴气；
∙小心眼、爱面子的团队成员会因为某个技术观点不同而怀恨在心，搞拉帮结派，不团结。
▪无论原因是自身不成熟，还是管理经验、管理能力不足，结果都一样，那就是项目出问题，甚至失败。
▪项目经理最重要的一项任务就是跟踪与控制，时刻把握项目方向，保证项目计划得以顺利执行，让偏差控制在可控风险范围内。
项目经理一定要时刻保持头脑清醒，对项目无益的事情不做，对项目产生风险的事情更不能做。
▪项目经理一定要能明确以业务为导向的目标，清晰识别哪些是成功的机会，哪些是失败的风险，少走弯路。
o3.6“如来十掌”与项目管理思路框架
▪1.确定项目的工作内容（范围、需求）；
▪2.确定这些工作要在什么时间完成（时间、进度）；
▪3.确定这些工作要花多大代价完成（成本、财务）；
▪4.确定这些工作做到什么程度才可以接受（质量）；
▪5.弄清需要谁来完成项目，以及组织内部有没有这些人力资源（含知识、技能）；
▪6.如果没有足够人力资源，需外包一些工作给其他人（采购、合同）；
▪7.项目所涉及的内外部干系人之间需要协调一致（沟通）；
▪8.识别哪些不确定性会促进或妨碍项目成功，并加以管理（风险）；
▪9.如何实现干系人期望的控制并获得干系人的满意（干系人）；
▪10.在上述九个相互竞争的目标下，实现最优（整合）。
o3.7烦人的客户需求
▪需求才是项目管理的第一难题。
需求，总有填不完的“坑”。
▪关于需求最为经典一句：
“我确实说不清我想要的东西是什么样子，但是我能说清的是你给我的东西不是我想要的！
”
o3.8从期望到需求
▪用户压根不知道自己需要什么，直到你把它摆在他面前
▪现在很多项目人员嘴里嚷嚷着的更像是“期望”，而不是“需求”
▪用户基于他们的阅历与认知习惯将自己的需求套到现实中的物质中。
▪福特汽车公司创始人亨利·福特询问客户有何需求，得到回答：
“要一匹跑得更快的马。
”他们回答“一匹跑得更快的马”，但并不意味着这就是他们的需求。
需求是客户表达出来的期望，就是那匹更快的马。
翻译过来，他们真正的期望是“速度更快的代步工具”。
▪用户真正期望的东西找到了，福特并没有给他们一匹更快的马，而是一辆福特汽车。
这辆汽车就是我们所说的“产品需求”。
▪产品需求实际上是产品所具有的功能和特性，它基于用户需求，需要结合产品成形。
产品需求是用户需求的进一步提炼。
▪项目需求——为实现产品而开展的工作。
▪当用户提出很多意见时，往往包含他们对这个问题的定性与解决方案。
所以，我们往往听到的是“你在这里加个××按钮”“这不行，得那样才行”。
其实，就像用户使用产品只是想完成他们的任务，而不是来体验的一样。
他们给你提各种期望也仅仅是为了更好地完成任务。
所以，我们需要对这些期望过滤，得到用户的需求，然后再结合自身得到产品的需求，最终迭代到产品。
o3.9谨防投射效应
▪横看成岭侧成峰，远近高低各不同
▪投射效应是指以己度人，并强加于他人的一种认知障碍。
主要表现是，认为他人具有与自己相同的特性，把自己的感情、意志、特性投射到他人身上。
▪每个干系人对项目的目标都不尽相同，项目经理要谨防投射效应的负面影响，不要以自己的认知和喜好定义项目的需求和目标，更不能完全从技术角度看待项目的目标。
▪我们觉得好没有用，关键是干系人（客户）觉得好才有意义
o3.10区分想要的和需要的
▪项目实施过程中出现需求困惑的重要原因是干系人想要的与真正需要的之间存在差距。
差距产生的原因可能是客户对技术激动不已，迷恋于在某处看到的东西，他们说自己一定要拥有它，却不考虑这是否是自己真正需要的。
▪麻省理工学院的经济学教授丹·艾瑞看到了这个方案以后感觉很纳闷，于是找了两组实验对象进行了对比测试，结果令人吃惊。
◎当第2种方案不存在时，84%的人选择第一种方案。
只有那些完全不缺钱或更重视阅读体验甚至收藏杂志的人——占16%左右——选择第3种方案。
◎当第2种方案存在时，32%的人选择第1种方案，68%的人选择第3种方案。
换句话说，第2个方案唯一的用途就是使第3个方案显得特别超值，在这种超值的感觉诱惑之下，很多人忍不住多掏了更多的钱。
▪请时刻记住以下几点：
∙项目中给干系人需要的而不是他想要的；
∙想要的很多，需要的不多；
∙想要的是理想的，需要的是能解决业务问题的。
o3.11切忌“鸵鸟心态”
▪“鸵鸟心态”，是一种不敢面对问题的懦弱行为。
其结果只会使问题更趋复杂、更难处理。
就像鸵鸟被逼得走投无路时，就把头钻进沙子里。
▪多数人不想过早地和客户纠缠一些问题，只是因为怕麻烦。
问题不谈的话，眼前还可以走下去，一谈就可能会变得复杂……说实话，有时谈清楚是“技术”，不谈清楚是“艺术”。
的确存在一些“只可意会不可言传”的东西，这是干系人管理的问题。
▪从现实角度而言，如确实有问题存在而且早晚躲不掉，假如争吵不可避免，早吵也会比晚吵好。
一方面，问题在早期解决代价会比较小，后期就会付出很大的代价；另一方面，尽早暴露问题，吵完了大家也就可以安心地做事了。
o3.12需求是要确认的
▪记住：
拿不到签字，下一阶段就不能开始。
▪其实，我们真正想要的并非他们的签字，而是逼他们认真考虑项目问题。
▪在需求和范围确认这件事上，项目经理需
升级会员 