PM培训的答疑课小结

标签: 前端开发 | 发表时间:2012-11-13 19:53 | 作者:sapphire
出处:http://www.aliued.cn

原文出自 独占神话

这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题。对学员们和讲师的讨论,我做了些小结如下:

一. 项目失控怎么办?

产生这种情况说明项目管理已经存在大的问题了。要做到的是提前预知,避免这种情况的出现。
万一出现了,首先要深入了解原因。多问自己问题,是人的原因吗?因为开发是新人?负面情绪引发懈怠?还是沟通不畅? 再看如何解决。两个方向,项目内搞定或者项目外搞定。项目内可以搞定吗?回答这个问题的关键是找关键路径。看从非关键路径是否可以抽调资源到关键路径上。这是要注意关键路径的变化。如果没法解决,项目外解决。项目外也就是看 项目管理三角形,在资源、时间、范围上找解决方法。

二. PM如何建立威信?

其实PM需要建立的不是威信,而是信任。这里提到一个非常有趣的概念, Johari Windows。乔哈里之窗能够用来展现、提高个人与组织的自我意识,也可以用来改变整个组织的动态信息沟通系统。
乔哈里之窗把人的内心世界比作一个四格的窗口:
The Open Arena:开放区,自己和他人都知道的领域。
The Hidden Facade:隐藏区,自己知道别人不知道的领域。
The Blind Spot:盲区,别人知道但自己不知道的领域。
The Closed Area:封闭区,双方都不了解的领域。
真正有效的沟通,只能在公开区内进行。因为在此区域内,双方交流的主题是共知的,沟通效果是会令双方满意的。实际沟通中,很多情况下信息不对等,处于封闭区,导致沟通无效。要使得沟通更有效,需要增强信息的真实度、透明度,进而扩大开放区。扩大开放区的方式可以经由自我坦诚,或经由反馈。

三. 遇到能力强但固执的项目成员怎么办?

1. 识别出其固执的原因。
2. 和其身边的朋友多沟通,对其个性和行事风格等更多了解。
3. 使其承担责任,成为某个课题的owner,自我价值实现。
4. 多搞团建,和团队融合。
5. 不能被团队认可,请出项目组。

四. 跨团队的资源如何协调?

1. 要清楚的认识到,我们不是去要资源,而是要取得一致目标。是我们大家一起要把这个事情做出来。讲讲清楚要做什么,得到认可,把事情变成大家的事情,而不是变成对立。
2. 要有结果,要及时反馈。

五. PM要对技术方案负责吗?

PM对技术方案影响越少越好,要认清PM的职责,是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物,他们去负责。
这里又涉及到PM正确的心态应该是怎样的,一是善假于力,融会贯通。对人,要知人善任,了解团队,了解成员的长处短处。对事,项目管理各个环节都要融汇进去。二是正向关注,助人自助。对人,给人机会,也要慎重淘汰。对事,接受挑战,积极正向。

相关 [pm] 推荐:

从编辑到PM

- 小鱼 - 所有文章 - UCD大社区
春节前收到一封陌生人的来信,一位网站频道编辑,向我咨询转型PM的可行性. 他问道:“你觉得做媒体和做产品,以前一样么. 话题很有趣,我也乐意就此写点什么. 遗憾的是,编辑转产品的成功概率却是不高的,就我的经验来看,存在四个障碍. 媒体工作需要捕捉阅读的共性,即“大家都爱看的内容”,相对来说比较忽视用户的个性化特征.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

PM札记:产品设计这两年

- - 所有文章 - UCD大社区
做产品差不多也两年左右了,基本上这条路是磕磕绊绊,迷迷糊糊,但好歹大方向是正确的,有空回想总结起来,唏嘘不已,看看以前对产品的看法,再看看今天对产品的认识,不仅感叹自己当初的幼稚,如今,更多的是了解了自己的无知与渺小,怀着一颗谦卑的心,继续学习,在产品这条路上寻找自己的价值. 产品职责包含很多东西,产品设计只是其中的一种职责,只是简单的描述一下我在产品设计上的弯路,回想起我的产品设计生涯,目前走过了三个阶段:.

PM培训的答疑课小结

- - 阿里巴巴(中国站)用户体验设计部博客
这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题. 对学员们和讲师的讨论,我做了些小结如下:. 产生这种情况说明项目管理已经存在大的问题了. 要做到的是提前预知,避免这种情况的出现. 万一出现了,首先要深入了解原因. 两个方向,项目内搞定或者项目外搞定. 回答这个问题的关键是找关键路径.

浅析PM工作流引擎

- - CSDN博客推荐文章
1.      JBPM工作流引擎是用来做什么的. 首先要说明的一点是工作流引擎指的并不只是JBPM,JBPM只是工作流引擎的一种. JBPM利用JPDL流程定义语言将现实生活中处理事务的业务流程进行抽象,形成一套业务流程规则,只要处理该项业务就必须按照这个流程规则进行. 举一个很简单的例子,就拿看医生来讲,看医生的整个流程必须是先挂号,再看病,再抓药,只要你进行看医生这个业务就必须按照这套流程进行.

如何防止架构师PM化

- -
和一些做项目主架构或者一号位的同学聊天,经常会听到一种说法:项目主架构做着做着就会做成PM. 这背后什么含义呢,细品下来有几层意思:. 整个集团的架构非常复杂,涉及的域众多,做主架构或者一号位需要大量的协调投入;. 不同域之间的资源错配现象严重,需要投入大量精力在锁定资源和推进排期上;. 项目结构过于复杂,PM催主架构,主架构催域架构,域架构催开发,层层订,各种站会,代码没几行,会议一大堆;.

您的团队需要什么样的PM?

- - 所有文章 - UCD大社区
     在腾讯,多数部门的实际采用了职能化或弱矩阵的组织结构形式. 中心和小组等组织层级实质属于职能线条,产品、开发、测试、运营、运维等职能角色是产品运营的主要角色,而各部门都会或多或少有一些全职或兼职的PM组织管理着各类跨职能活动.       基于各自情况的不同和各自对PM职位理解的差异,对PM职位的定位也千姿百态.

PM成长日记:从需求到产品

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
   本文作者系大众点评产品经理@ 七手八脚裸奔地小石头.   本篇本来打算写如何跟技术进行沟通,其实跟技术的沟通,是贯穿于整个从需求文档到产品上线、产品跟踪、迭代的过程之中的. 本篇更多的是讲作者工作半年来,从需求文档到产品上线的过程,也希望与同行朋友多交流.   当你辛辛苦苦写出来一堆需求文档,跟UED的同学定好交互、视觉、重构;满以为技术会认真对待,但是你会发现,技术同学基本不会看你准备的一堆东西,基本是按照自己的理解来开发,当开发不下去,第一时间也不是看文档,而是看测试用例,或者直接跟产品沟通;基本文档只是QA同学对着写用例.

作为一个PM 该如何做好产品竞品分析?

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  在企业中竞品分析工作大多数产品经理实际工作中很少去做,要么由市场和运营人员代劳,也或者产品部门配备市场研究相关岗位定期来做. 而近来部门同事实行每月对现有产品进行竞品分析,参与一部分工作. 对于既不是专才和通才的产品经理来说也是一种全新历练和学习.竞品分析结果只能作为一种参考依据(由于信息挖掘渠道和关注点都相对带有主观性,比较危险的是有些产品经理会特意朝预期潜意识心里判断来收集数据),通常服务于领导及产品管理层对产品信息动态能够有意识的去关注及时调整相关目标;.