在公司里，项目经理看似权力很大，其实很难协调工作，怎么办？

Posted 2023-03-11

参考技术A 说一下我的观点：

1、什么是权力？权力是人与人之间的影响力，是一些人对另一些人造成他所希望和预期影响的能力。提问中说了，公司表面上赋予了项目经理很大权力，但实际在用的时候却发现所赋予的权利是虚假的，只是说说而已。之所以你协调不动，一个重要原因就是并没有得到真正的授权。

2、我比较反对所谓的协调权利，协调的后果，完全取决于被协调方的自身意愿，对方愿意配合，那么协调成功，对方不愿意配合，那么就协调失败。干革命不是请客吃饭，工作也不可能你好我好，把希望寄托于他人身上，不如意者十之八九也是正常的。

3、站在相关部门的角度，项目管理具有临时性、复杂性、不确定性的特点，大多数情况下都会带来额外的工作量。很多公司做项目的时候抽调了很多骨干人员，结果项目做完了，原来的岗位已经被人替代，反而无处可去了，你说说谁愿意冒这种风险呢？

4、说一说怎么改善，实现项目经理的目标：

首先，你要清楚，项目经理的授权来自于公司决策层，更准确的说来自于一把手。没有一把手实打实的支持，那么所谓的授权都是空中楼阁。我们公司的做法是定期召开总经理参加的项目例会，将项目的状态、问题和推进方案与总经理沟通共识，将需要安排的工作通过总经理确认的方式予以责任化，这样大家干的活就变成总经理安排的，而不是项目经理安排的，权威性自然就有了。实在开不了会，任务清单让总经理确认，通过总经理下发也是可以的。这样做，也帮助项目组人员在决策层那里混个脸熟，弱化对于未来职业前景的担心。

第二，手中有粮，心中不慌。项目经理要想能协调的动其它部门，就必须拥有考核权、激励权。我们之前的做法是项目期间，项目组成员均以项目经理考核为主，原部门考核为辅，同时考虑到相关人员身兼多岗的实际状态，给予项目经理额外资源，用于对项目组成员的激励。

以上，供参考，祝好运！

俺曾经获得某行业全国年度优秀项目经理，我认为沟通协调是优秀项目经理必备的能力之一，也是项目经理的重要工作之一。

从沟通协调的对象而言，可分为内部干系人和外部干系人。内部干系人沟通协调可分成向上沟通、平行沟通和向下沟通。

向上沟通首先应遵循“知”的原则：通过项目进展报告、工程例会汇报项目进展，让各级领导了解项目进展、项目风险和需要组织支持的事项。也可以通过微信非正式沟通，必要时专程拜访领导汇报工作。

这不是拍马屁，领导对你负责的项目情况很陌生，出现问题时你怎样让领导理解你支持你？

平行沟通包括与企业内部职能部门、管控部门和生产部门领导的沟通，项目经理应设法取得其理解、支持和指导。

有些项目经理除了开会和书面汇报（项目进展报告），就不愿与这些“当官的”过多接触，这样不行！这些中层干部也是有感情的，你尊重、理解他们，他们也会理解你，因此衡臣建议项目经理从现场回到单位，抽空到相关部门领导那里坐一坐、聊聊天，一定会促进相互之间的理解。

记得衡臣完成一个总包项目后马上又接了个新项目，衡臣请了六个部门的领导吃饭，主题是“感谢”和“拜托”，感谢他们在前一个项目的理解和支持，拜托他们继续支持新项目。结果六个部门的正职副职都来了，比某些领导组织开会还齐，这就是有效沟通的效果。

向下沟通要掌握以下几点：

1、项目经理应通过策划和制度建设使得项目管控清哳而有序，提高项目的规范化管理水平，否则容易打乱仗，打乱仗大家心情就不好。

2、一个好汉三个帮，项目经理应注重与核心团队成员的沟通，以个人品德、能力服人而不是以势压人。衡臣每个项目初期，再忙都抽出时间与每位核心团员成员聊上半天，听取他们的意见、了解他们的需求，提出自己的想法，你真诚待人人才会真诚待你。

3、所谓领导要为下属有效率的开展工作创造条件，这是强调项目经理的服务意识，对下属的工作进行事先指导、中间检查和事毕验收总结，三者缺一不可。

4、要注意沟通方式，“不在下属的下属面前批评下属”是衡臣遵循的原则，谁都可能犯错，重要的是知道为什么会犯错，衡臣通常都是关上门单独批评下属，改进了就要表扬。

5、要有“ 情感 管理”的思维， 情感 管理在国外是一门学科，项目经理要关爱下属，努力为他们创造较好的工作和生活条件。衡臣在新疆某项目上专门配置了“探亲房”供下属家人来探亲时使用，此外考虑戈壁滩生活单调，为了保证员工的心理 健康 ，每半月轮流组织外出城市“放风”。因此，即便现场条件艰苦，没有一位流失离开直至项目结束。

6、要懂得授权，项目部成立初期项目经理要加强指导，中期要懂得授权，要注意在外部干系人中维护核心中层的威信。有些人会介绍“这是我的项目副经理”，而衡臣总是说“这是我拍档”。

项目经理必须有强烈的目标责任感，为了实现项目目标要知进退、忍辱负重，切不可任性。

有些项目经理在协调时遇到困难，往往认为自己己经尽力了，结果不好于心无愧；有些遇到困难不敢得罪人，往后缩。却不知企业授于项目经理权力，项目经理就得承担责任！

衡臣为了推动工作进展确保实现目标，有时不惜得罪领导，因为衡臣知道：只有结果好才是真的好！项目成功了，过程中得罪领导的事算得了什么，项目失败了才是最大的得罪领导。

这里举二个例子：

案例一：

项目遇到困难，主管领导到项目现场协调时大家说得挺好，领导回去后打电话落后诸多借口，这也不好办那也困难，衡臣一纸“备忘录”将现场开会方案主送项目主管领导，抄送主管领导的领导。结果怎样？主管领导乖乖的在备忘录上签“同意”。

案例二：

项目设计进度不够理想，衡臣借助外力主动让业主写了份“告状信”，告状信到单位后，衡臣给人骂惨了！有什么关系，目的达到就可以了，得罪人再想办法去弥补。事实上，项目成功大家脸上都有光。

最后协调复杂的事项要记住“做最好的努力，作最坏的打算”，条条大路通罗马，千万不要一根筋走到黑！

衡臣推崇“凡事上、中、下三策”，努力争取上策解决问题、做好中策的各项准备，至于下策除了心理准备，还应做好应急预案。

初次了解产品

  　  产品经理在不懂的人的眼里不明白是做什么的，或者说经理级别的，好高大上，其实你要是跟别人说你是做app的，那么许多人就了解了。

　　其实通过上述的一个小例子来说，在产品的角度上讲，如果你诉说的对象是公司里其他部门的人，比如开发，测试等等，如果不说清问题的本质的话，是很难让工作继续下去的，因为你首先要一针见血的表述出你想让开发做的需求，或者你跟测试或者交互交代清楚各个功能模块的功能设计，而并不是模棱两可的去说你的需求。

　　产品周期，产品周期一般分为四个时段，探索期、成长期、成熟期、衰退期。而在探索期到成长期之间版本迭代是非常频繁的，在这里产品不要局限于本次的迭代，而应该在本次迭代成功后，即即将上线的时期，就要筹划下一次版本迭代的内容和时间，并通知各个相关部门。在产品的设计和上线后，一定不要考虑近期的效益，因为产品是一个循序渐进的东西，在你设计时，并不一定要着急去做某个模块的设计或者需求分析，而是从一个大的层面考虑为什么要做这个产品，做这个能干什么，后期如果做了怎么去运营，如果确定好了以后，也不要着急的去做具体的设计工作，而是熟悉你要做这个产品核心业务的业务流程是个什么样子的，它的业务逻辑是什么样子的，在熟悉后要详细的对用户做需求分析，在这里可以运用“五个为什么”的方法去询问，并且用黑箱子的方法去引导用户说出他的核心需求并整理出一份需求文档，（提一句这个需求文档所包含的需求不只是包括使用人群，比如还有老板、客户、运营、销售等等方面的需求综合在一起），并且分析出1-3个核心需求，因为你在做产品的时候不会一下做许多需求，而是围绕自己的核心需求去做功能，（提一句，再最后确认好需求后，再将需求产品化，并且应该讲每个核心需求用官方语言概括出来，这个是后话啦），核心功能确定好以后，要做的就是梳理核心业务流程，画流程图和脑图写需求文档和画原型，当然别忘了在这之前，要好好的跟开发和设计师以及测试好好的进行沟通，告诉他们你是怎么想的，当然啦，你也可以开一个需求分析会，将自己整理的一些想法或者一些草图给开发设计以及测试看，这时要好好梳理业务流程和需求的取舍，因为在好的想法遇到现实也是骨感的，因为得考虑技术的可实施性，以及在交互时会不会产生不必要的麻烦或者对用户造成不必要的操作上的重复或者复杂。

　　当需求分析会沟通完成后，就要确定需求文档和原型设计，这时开发开始进行开发以及交互设计也在进行，产品要做的就是跟进项目的进展，并且不断地在用户或者老板之间游说，因为会时不时的有新的需求提出来，有的可能天马行空，不切实际，但是有的却是可以实现的，这时还是得及时跟开发和设计及时沟通，并且及时更新需求文档，方式有很多种，可以直接过去说或者及时性邮件或者有一个固定平台，固定时间进行内容更新。（当然这都是我个人想的哈哈哈），后面就是测试同学们了，这里产品应该没什么特别要跟进的，因为都是在挑bug，除非是特别触动到业务逻辑层次上再去干预。

　　后面就是产品上线等等一些事情，其实还得写好多啊，哈哈，比如内测版本先发布一个，范围（如果版本是从0到1），那么可以让公司的人员进行体验，并且及时了解产品的不足和bug。并且个人觉得还是将这些数据化更合适一些，因为数据大多数的时候更让人信服，这时应该再一次开一次会议，或者说产品部门自行召开，在联合其他部门召开，（这也是自己想的，因为产品是一切发起的源头，也应该最明白产品的功能和核心的业务逻辑），等梳理清楚后，在召开部门与部门之间的会议，进行版本的迭代，最后上线。（因为在上线的事情还不是特别的了解和理解，所以有很多情况考虑不到，应该多思考）

　　上线后就是分析产品的有点与不足，并且培养种子用户，增加用户使用量。另外在上线的版本上，依靠设定的诸如数据埋点获得用户真实数据，或者用户对某个功能模块在评论区的评论等等，来作为下一个版本更新迭代的重要依据，（其实在新产品上线之前，其实产品经理本身就应该结合市场和已确定好的特定用户进行新一轮的产品迭代的工作的开展，另外要考虑潜在用户的用户行为，为产品用户数量的增加埋下伏笔，当然更新迭代后没有促进用户数量的有效增加，可以考虑各方面因素，有选择的去掉某个功能）下一个版本上怎么增加用户基数。（具体操作可以根据各方面反映上来的需求，通过双钻设计进行产品的更新迭代）

　　好啦写了这么多，其实并没有很工整的去写，只是随笔记一下，让自己复习复习这两天的学的东西。个人观点，欢迎指正。。。。（小白一个）