精华内容
下载资源
问答
  • PM什么意思

    千次阅读 2010-12-22 17:13:05
    请注意:本文章的 pm不涉及 论坛上private message (私下发信息)和 下午post meridiem 等意思。旨在探讨产品工程师这种职业的工作内容和职责,如有好的相关信息请联系觉得这个职业能锻炼你...

    http://taowei54.blog.163.com/blog/static/1026885072009228114824414/

    转载的文章

     

     

     

    请注意:本文章的 pm不涉及 论坛上private message (私下发信息) 下午post meridiem 等意思。旨在探讨产品工程师这种职业的工作内容和职责,如有好的相关信息请联系我。我觉得这个职业能锻炼你的沟通能力,如果你要学习技术,它是应该不会让你学到很多。而且工作内容很单调,经常出现各种突发事件要你去处理。需要你了解各个部门和生产流程中的事情,你需要站在很高很广的角度上为公司考虑,熟悉各个部门的内容,并有效的进行沟通,把客户,公司内部之间的问题,协商解决。你会有一个进度表,按照上面的时间把指定的任务搞定,有时候客户会要求提前时间,你就要去在很短的时间搞定,很费精力。有时候觉得客户的要求都不一定能完成,但客户是上帝。

    pm项目管理定义:有計劃的組織、用人、指導與控制的過程,充分運用企業的資源包括資本、物料、時間與員工等,以達成企業的短期目標。專案管理是應用管理知識、技能,在既定的時間及預算下,完成專案目標與需求。

    專案管理之特性
    強調系統觀念及整合功能
    l   
    專案經理為專案管理之重心及中心
    l   
    專案經理常與各部門主管爭取機構內資源
    l   
    運用臨時性組織
    l   
    專案管理與傳統(功能)管理交織成網狀權責關係
    l   
    專案管理應有適度彈性
    l   
    評估專案管理不宜單以專案成敗為基準

    pm是一种职业 项目管理 跟进产品进度的, 好像目前只有臺灣企業有這個職位, 主要負責新產品開發階段的管理工作, 包括設計、採購、生産、送樣等過程中的協調管理,平時工作中需要和單位的很多部門協調溝通, 主要有業務、採購、製造、品保、研發等部門。   PM是英文Project Management 还有 pee产品工程师。以前有个论坛我看到pm的指责讲的相当到位,现在找不到了,pm这个职业的网上的信息是太少了,搞的我都不知道到底是哪两个单词,继续搜集相关pm信息,请关注

    pm Product magagement (PM)/翻译过来是专案管理或项目管理   这个意思。 以下为收集到相关pm信息:

      深入挖掘pm这个职业的意思

    PM是最有前途的,不过最好先做R&D这个意思是研发部research and development 研究与测试,研究与开发)吧,那样以后就可以做项目经理了~   PM项目管理,我们老大说,要害一个人就让他去做PM,因为做PM阵亡的最快,要想往公司高层爬呢,就要去做PM

    PM对于不同的企业,所做的工作不完全相同~~但有一点的同的,那就是协调生产各个环节~~
      说好听点你是个项目经理,难听点就是打杂的~~~而且超累
    PM:product manager
    (产品经理)负责根据市场负责公司产品的选型,更新,等一系列工作。很累,很烦。有些公司的PM是有业绩压力的。

    2004年曾经去Foxconn做见习 PM,做完3个月就离开了,不过还是学到蛮到管理、有效沟通方面的经验,值得去做

    我也是做PM的,但是感觉工作中离我喜欢的技术越来越远,因此越来越有危机感

    职责:

    1.设计图纸,验证产品零件,组装,问题点检讨;
    2.
    文件资料归档;
    3.
    与其他部门、客户及厂商沟通;
    4.
    等等
    PM
    Project manager的缩写
    传统意义上PM就是一个产品的主管,为了方便讨论,我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。
    作为一名领导者,PM将对整个产品的成功负责,这其中包括用户体验。对技术产品而言,用户体验是产品成功中非常重要的部分,当然还包括其他方面,像产品的销售、技术、法律、商业模式、定位、品牌和营销等。
    PM
    的基本职责是理解市场并推动适应市场的产品开发,由于UE人员往往已经熟悉了设计的用户需求也具备相应市场知识,因此他们具有成为优秀PM的潜质。
    PM
    还有如下一些较高层次的职责:
    ?
    建立产品策略,重点是对产品的未来有长远和有说服力的眼光。
    ?
    将策略转化为产品路线,有了清晰的远景和策略后,PM就要与管理层一起确认并执行策略。
    ?
    撰写支持商业策略和市场需要的需求书,确定主要路线,然后细化特定的可执行的需求。
    ?
    确定以合适的顺序,在合适的时间提供合适的功能特性(features),以客户价值和市场的关联程度来划分这些特性。
    ?
    确定与市场间有适当的沟通渠道,以合适的方式向合适的人发送合适的消息,并确认客户已了解到他们的产品。

    这篇文章之后,也是颇有感慨。结合一下目前为止出现在工作中的情况,也产生了很多疑问。偶尔在奇遇的博客上看到这篇文章,感觉应该与大家分享一下,也许这并不一定适用于我们现在的工作,但是我想,这也有一定的借鉴意义。以下是他的文章:

    以下一段来自http://blog.sina.com.cn/s/blog_4d9cecc401009cdm.html

     

     

     

     

      协作,而非争权

     

      前段时间在Banlon哪里看到你是否在边缘化这篇文章,引用词句如下:

      你是否发现,越来越多的时候,程序员向产品经理询问一个按钮的尺寸,而不是向你?
      你是否发现,越来越多的时候,产品经理让你帮忙画个图,第二天就要?
      你是否发现,越来越多的时候,你的合理的方案被否定,固执的产品经理按照他们的思路确定了解决方案?
      你是否发现,越来越多的时候,你在被动的做事情,而且,你的事情越来越少?

     

      然后据此号召设计同行夺权,如果是真实的被边缘化,我不反对夺权。但换另一种思维,PM的存在是为了更好的工作,而非要代替设计师,PMUE是协作,而非利益的争夺。

     

      且让我们看一下UE各部分的职责(注意,各部分不是说各职位):
      用户研究:主导对用户的调查研究,主要是用户文化、交互行为、用户角色设计、用户场景设计、用户测试等,同样这些研究为产品定位和设计提供依据。
      信息架构和交互设计:主导产品的表现架构、交互模式及细节等设计,同时主导产品功能确定。
      视觉表现:主要视觉表现层设计,包括所有界面的视觉。

     

      那么PM做什么?其实PM做的事情很重要,要为具体干活的人提供好的平台
    产品定位:做产品的市场定位和设计定位,或者辅助UE做产品设计定位。
    项目进度安排:产品从概念–>设计–>实施–>测试–>发布的整个过程,应该由PM和公司高管共同拟定计划。
      协调:负责相关部门的协调问题,当然内容很多,包括召集沟通会议,矛盾的裁决,承担很多扯皮的事,让各职位安心的各司其职。

     

      通过以上的分析,我们可以清楚的看到,PMUE是在协作,UE各部分的设计师都有其主导的内容,如果该UE主导的部分被PM主导了,那么你是得考虑自己是干什么的了;如果只是开发人员问PM一个关于设计的问题,PM也有义务告诉他们,因为这是协调,并不影响你的设计。

     

      好的平台必定有好的协作,确切的说是由好的管理和组织形式,UE在好的环境下才能好好的干活。确实如此,如果产品经理固执的在替代你做设计,在固执自我的观点,你们就不是在协作了,是在扯皮了,而这正是PM要避免的,矛盾呀!其实除了管理之外还有一个关键,就是优秀的UEPM,要不一切无从谈起,更别说我们所追求的理想状态了。

     

      小结:让我们时刻记住,字当先,我们是在协作,不是在争权,更不想UEPM谁把谁干掉。

     

    以下文章来自http://hi.baidu.com/pdw666/blog/item/927e2607ce311ccb7a89474c.html

    给新手PM1 - PM像什么

    你好!恭喜!

    你选择了踏上项目管理这条路,这是很棒的方向,可以学到最广泛的经验,非常恭喜你!在这个行业里头,需要很多项目管理人才,尤其是好的项目管理人才,这绝对是值得你努力耕耘的方向。

    你问我:什么样的项目经理才是好的项目经理?这个问题很好,但是很难简短的回答。以后我会慢慢告诉你,如何当一个称职的项目经理,不过既然你问的这么诚恳,为师的也不能随随便便回答。

    我们换个简单一点的讲法好了,好的项目经理应该要像什么?

    首先,好的项目经理要像狮子,要具备狮子的自信与领导气质。狮子是万兽之王,能够镇慑其它动物,像狮子一样的项目经理,就是一个具备领导力的项目经理。任何一个稍具规模的项目都必须整合多人跨领域的团队或资源,才能完成任务,如果团队没有好的领导人,再多个厉害角色凑在一起也只能算是乌合之众。而项目经理名为管理项目,实际上却不只管理项目团队而已,而是必须领导项目团队。至于什么是领导,我们改天再说。你呢?其实也不用想太多,就先当自己还是小狮子吧!总有一天会长大的。

    好的项目经理要像磁铁,要能够把项目团队及资源牢牢吸住,但这个牢牢吸住却又不是锁螺丝那么难拆解,万一团队成员要更换或者资源安排到另一个更重要的项目,也不能太难处理,像那句有名的广告词"有点黏又不会太黏"就对了。我想强调的重点其实是"凝聚"的力量,如果项目经理是够强的磁铁,就会将项目团队紧紧拉拢在一起。而且这个拉拢的力量,是有扩散性的,被吸住的团队成员就像具备磁力的铁片一样,会自动吸住他该关注的项目跟任务。

    好的项目经理要像大海,要有肚量。这不是件容易的事情,如果你不当项目经理也许就不用太在意,要当项目经理肚量太小,恐怕很快的就会高血压心脏病了。因为项目经理身处项目风暴的核心,上有老板,下有团队,旁边可能是其它项目团队或者部门主管,外面还有客户跟外发厂商,每个人有每个人的意见跟看法,如果肚量不能像大海,海纳百川而阔,大概天天都在跟其它人争辩意见,那就不妙了。

    好的项目经理要像水,不管项目过程有多么崎岖难行,你的身段得柔软地去适应并且抚平。这绝对不是简单的本事,遇到凹陷的地方,这是你的项目团队的不足之处,你必须注入你的能量加以抚平。遇到客户要求过多,就好像平地上冒出的土丘,要不把土丘给抹平,要不就放大水来淹没 (仔细想想这个描述真有点离谱)。能够让项目的表面看起来平平整整的,那是项目经理的上等功夫。当然,水面下的起起伏伏,那就是鸭子滑水了,该不该让其它人知道你的劳累跟贡献,如何让其它人知道,这就得看场合跟状况了。

    好的项目经理要像竹子,韧性要够,要不怕风吹雨打。虽然要像大海听别人的意见,要有水一般柔软的身段,但这可不是教你去奉承逢迎,别忘了项目经理要领导团队不是只靠附和他人意见,最基本的还是自己的专业要够,要挺得住,即便是被巨大的范畴 / 无理的时程要求 / 夸张的需求变更所打击,也不能倒,倒了就没有尊严了。当然很多时候项目经理是可以稍微退一步以取得缓冲,便于在缓冲中找到解决方案。总之,不卑不亢就是最好的态度,只要最后能靠自己的实力站起来不被击倒,以后就会获得他人的尊重与认同了。

    用这种讲法好像篇幅再多也讲不完,以后想到再叮咛你,希望到时候你别嫌我太啰唆!


    给新手PM2 - 建立共识

    你上回说现在接手一个客户的小型网站改版项目,每次开会或者讨论事情,感觉大家都在看着你的意见跟表现,让你压力很大。你很想知道有没有什么秘笈可以快速的学好项目管理。这个问题很有趣,我也被许多人询问过同样的问题,只可惜,管理好项目没有快捷方式,我能够告诉你的东西,没办法速成,可是却是成功关键。

    如果你想了解到我过去做网站项目管理心得,那么我可以在这里告诉你,接下来的这个重点是我多年功力的菁华。

    评估项目经理能力高低,就看项目管的好不好。影响项目管的好与不好的因素很多,若全面分析所有因素并且逐一探讨跟检视,恐怕讲三天三夜也讲不完。

    今天我先讲第一个成功关键因素,这个因素是我认为最难最难的一件事情,如果能够把这件事情做好,即便是项目结果不如预期,但大家可能都不会怪罪到项目经理头上。

    第一个关键因素是「建立共识」。

    什么叫做共识? 简单说,就是全体人员有相近的看法或者支持相同的决议。

    那么哪些人要有共识呢?

    首先,你的内部团队要有共识,包括上头的老板,甚至老板的老板,你的技术团队,你的设计团队,你的企画研究幕僚,甚至你的下包厂商,

    再加上客户端的共识 (这里所指的客户端,也包含项目委托单位是自己企业机构内的其它部门),客户的项目小组,客户窗口的老板,或客户窗口的老板的老板。

    最后则是你的项目团队与客户端的项目相关人之间要有相同的共识。

    项目管理理论所谈到的各种管理作为,有许多都是为了促成共识的措施,包括定义项目的产出规格与质量,项目工作的分工与接力,合约/计划书/会议纪录,沟通技巧与方式 (各种形式的沟通, 会议, 电话, email, 文件…)

    管理项目的共识,根本上必须是项目经理的习惯,连想都不用想,随时随地要意识到让大家形成共识。在项目过程中的每一个动作跟步骤,都要提醒自己是否已经形成共识? 如果还没有共识, 会造成什么后果? 要透过什么样的决策机制来定义共识?

    总之,项目的任何一个环节疏忽了建立共识,就有可能埋下后面造成项目范畴或规格变动的隐忧。形成共识,被我视为项目经理的第一要务,只要能够做好共识的塑造与形成,就是大功一件。

    由于共识的建立牵涉到人的认知与沟通,偏偏只要跟人有关的事情,就是最难搞定的。只有两种情况,共识相当于等于项目经理的个人意识,此时几乎没有沟通成本或沟通问题。

    第一种情况,项目经理自己是委托端及执行端,而且是自己独立执行的项目。这种情况也许很像是有些程序设计师自己设计一些软件或网站,自己玩一玩。

    第二种情况,是所有人都听项目经理的。什么情况会这样? 当项目经理的专业够水平,足以服众,此时所谓的共识几乎就是项目经理的个人意见,而这种情况不多见。但假使项目经理的专业水平能够提高,就更有机会快速的凝聚共识。

    关于共识的建立,我们会再用更多更多的篇幅来讨论,如果你在这部份有什么心得或问题,我们可以随时回头再来检视这个题目。加油了!


    给新手PM3 - 配置资源

    没有兵的将领无法打仗,没有子弹的兵无法战斗,巧妇难为无米炊,项目经理没有资源就无法完成任务,这些都是一样的道理。这些道理的意义都在表达「资源」的重要性。而「配置资源」正是影响项目成功的第二个关键因素,资源的配置包括资源的评估、分配、取得、运用

    对新手PM来说,配给什么样的资源往往是别人做的主,这是比较无奈的一点。但是既然公司能够赋予你担任PM的要职,多多少少都相信你具备应用资源/管理资源的能力,换句话说,你自己得评估资源是否足够,万一领了军令上了前线,回头寻求后方火力支持时,才发现后头是漫漫荒野没有后援,恐怕你就准备阵亡了。

    「资源」包括什么? 包含为了达成项目任务所需要的「有形资源」,及「无形资源」。

    预算是资源,时间是资源,人手是资源,顾问是资源,下包厂商也是资源,为了达成项目所需要的各种实体对象,软件/硬件/图库/音乐版权,项目的大老板的某种授权或背书,皇上给的免死金牌/尚方宝剑等等都属于项目资源。


    理论上,拥有「无限」资源的项目,有最大的成功机率。不过这个描述已经违背的「项目 (Project)」的基本定义 (项目本身就有时间限制,否则不叫做项目)。参考wikipediaProject的定义 英文 中文。

    正由于各种资源都有其限制,因此将资源最佳化,达成最佳的项目产出与质量,就是项目之所以得被赋予「管理」概念的由来。

    反之,一个项目没有足够的资源,天生就埋下了失败的隐忧,所以,项目的关键成功因素之一就是先取得资源,或者讲白一点,取得足够的资源,而资源当然是越多越好。

    但站在项目经理的顶头上司或者项目委托人的立场,通常这两位大人是提供资源的重要人物,他们对于资源的取得或分配,考虑的角度是「资源最佳化」,说穿了,就是「足以达到项目产出基本质量的最低资源」。这不能怪他们,因为从你的角度你也许只看管一个项目,从他们的角度得看管十个或数十个项目,当然得顾及各项目的资源配置。

    曾经有很长一段时期,取得项目资源一直是我心目中项目成功的第一重要因素。在踏入这个行业的初期,曾受到一位软件业界前辈的指点,我也跟你一样想寻求项目管理专家的协助,前辈给我一个很重要的观念,我一直记在心里头,他说「项目要成功,首先你要有自己的团队」。换句话说,没有项目团队的项目经理,就像是没有兵的将领,无法战斗。

    拥有项目团队(Team)最快的方式,你知道是什么方式吗? 很简单,只要雇用一个英文名字叫做Tim 的人,就可以跟客户宣称我们有 Team了。这是一位好友在非常无奈的情境下,想出来的冷笑话,当时他就在没有Team的情况下苦中作乐,才想得出这种冷笑话。

    为了把项目资源做评估与规划,很多项目管理的理论都有谈到。首先项目目标与目的的定义,范畴的界定,规格的界定,人力/预算/时间的估计,将这些林林总总的项目作好完善的安排,形成项目计划,这些细节我们以后再来讨论。

    最后,帮你做个心理建设,没有一副好牌却仍能打出一场好牌局的PM,才是真正的高手。如果每个项目都能够赋予项目经理够多好用的筹码,每副都是好牌,坦白说,项目管理就没有什么价值了,我们今天也不用花心思做讨论了。不管你手上拿到什么牌,想办法打出属于你的一场好牌局,这是PM要最用心的地方。


    给新手PM4 - 提升客户与执行团队的专业

    距离上一封写给你的信,大约隔了两个半个月了。非常高兴得知,在我不能随时提供咨询的这段时间,你有自己的历练跟成长,而且还获得客户的肯定,很欣慰!

    言归正传,继续我们的「函授」教学还记得我前面两封信提到我多年功力的菁华吗?第一个重点是建立共识,第二个重点是配置资源,今天我们要来谈谈第三个重点。

    项目成功的第三个关键,以前我只放在心里面,不讲出来的。不讲出来的原因是这个讲法听起来一点也不专业,甚至不入流,那个关键叫做「运气」,不过现在我认为第三个关键可以修正为「双方团队专业程度的乘积」。

    为什么「运气」竟然是项目成功的第三关键呢?我们都知道项目时程,范畴,需求都是委托方赋予的,所以如果运气好,遇到好客户,项目就有较高的成功机率。运气好的项目经理,会遇到好的委托方,明理的客户,有合理的时程要求与项目范畴,找得到强力支持项目的高阶主管,预算够用甚至还可以到饭店来个期末庆功。

    回想我过去的经验,同时遇到这些极佳条件的机率非常的低,如果遇到了,表示手气好到买到乐透头彩了。只是项目本身都成立在这种理想状况,项目经理就不需要太厉害了,当然也看不出项目经理的贡献。这就是我上一封信提醒你的,没有好牌也要打出好的牌局。

    照这个道理来说,项目的命运岂不是永远掌握在客户手中了吗?那项目经理不就得背负着这个原罪,那也太倒霉了,谁还来当项目经理呢?因此把项目成功与否推给「运气」这是很不洽当的想法。就好像把项目能否成功的责任通通推给客户一样,这种讲法是完全说不过去,毕竟客户会将项目委托给你,有一种可能性就是他本身的专业上不足,需要你的协助,哪里可以借口客户水平不足而导致项目失败呢!

    不过最近几年,我发现这第三关键「运气」应该修正为「双方团队专业程度的乘积」。这个概念把被动的,运气的,宿命的消极工作观,调整成比较主动的,客观的,积极的工作态度。你听听看有没有道理?

    经过我的观察,实际上项目的最后成果,往往都是委托端的努力加上执行端项目团队的努力一起合力创造出来的。假设满分是100%,如果客户的水平达到80%,而项目团队也有80%,那么项目的成功指数就达到80% X 80% = 64%,大于60%勉强及格。

    如果你的项目团队的专业指数达到100%,但是遇到一个30%的客户,你想项目会成功吗? 成功指数就只有100% x 30% = 30%,不及格。反之亦然,一个专业水平有100%程度的客户,若遇到只有20%水平的项目团队,大概也就祇有等着遭受打击的份了。

    因此在专业水平上能够门当户对的项目团队与客户,才有促成项目成功的底子。重点在于双方的专业必须是互相弥补的:能够提升执行端项目团队水平的客户,是好客户;相对的,能够培养客户素质的项目团队,才是一个好的项目团队。

    所谓的双方的专业必须互相弥补,在网站建置类型的项目上,尤其容易看得出来这一点的重要性。委托端-也就是客户,必须很清楚自己的需求,以及所在产业的相关知识(Domain Knowledge);执行端-也就是你所带领的项目团队,则必须拥有良好的网站规划建置各项专业。

    当客户对自己的需求掌握90%,合作初期也能将他们的产业知识传递(或传授)给你的项目团队,再加上你所带领一群专业水平达90%的好手,我们放到公式里头就可以得到90% x 90% = 81%的好成绩。我曾经遇到一个客户,他把产品网站委外给小设计工作室,结果工作室倒了,人跑不见了,他的网站也跟着消失找不回来,因为他连备份的观念都没有。这个情境大概是50% x 40% = 20%吧!下场也够凄惨的。

    换个积极的角度来检视第三关键「双方团队专业程度的乘积」。你要创造好的项目成果,在项目一开始就必须考虑到,如何为第三关键的两个变量A,B创造出好的水平。

    变量A是「客户水平」,如果有机会一开始就筛选出好的客户,那很不错,假设没这种条件,就得跟客户「博」感情,借着多次的交互与接触,来教育客户,让客户素质成长。当客户体认到,你来做项目不只是做事情而已,他本身也可以获得很多的成长,客户会越来越信任你,依赖你,以后的事情就会越来越容易做。

    变量B是「团队水平」。一样的道理,项目团队的素质,就是项目质量的基础。如果你没有办法筛选,组织出好的项目团队,那么就得借着你手上的资源,陆陆续续将自己的团队素质加以提升,比如花更多的时间在学习,聘请专业顾问,编列课程培训预算等。经历这个过程,你的团队成员也认知到跟着你做项目,不只是做事,自己的专业也会提升,那么团队向心力就会越来越强,大家也会愿意跟随着你,以后的项目就会更容易成功了。

    所以,下一次不用太介意客户有多差劲,或者工程师/设计师有多不配合了,这些都是你在项目管理工作上必须经历的,而且这种情况发生时,你更应该要先做自我检讨,与其抱怨,不如更用心去提升各方水平,当你付出更多,很快的,你就会获得更多!不相信吗?试试看便知道!

    一解:PM是英文Product Marketing的缩写。PM的中文意思是产品市场。

    二解: PM是英文Project Management的缩写。PM的中文意思是项目管理。

    三解: PM是英文Project Manager的缩写。 PM的中文意思是项目经理。

    四解:PM是英文private message的缩写=PM的中文意思是私人信息,发信息给我的意思(常在论坛中使用)。

    五解:PM是英文PageMaker的缩写。 PM是排版软件。

    六解:拍马的缩写。

    七解:PMPolymethyl Methacrylate的缩写 中文名字叫做聚甲基丙烯酸甲酯

    八解:拍卖的缩写。

    九解:PM => 下午(AM => 上午)

    十解:PMPocket Monster的缩写。中文名字叫做"口袋妖怪"

    十一解:PM 是英文plan maintain 的缩写中文意思是计划维护,在现代的工业厂常有专人负责计划维护系统,用于设备
    定期维护

    十二解:PMPrimitive Member原始会员

    十三解:PMPower Manage的缩写,中文意思是电源管理。

    十四解:PM是发短信的缩写。post message 常指论坛的会员之间发短信息。

    元素符号: Pm   英文名: Promethium   中文名:
      
    相对原子质量: 144.913   常见化合价: +3   电负性: 1.13  
    外围电子排布: 4f5 6s2   核外电子排布: 2,8,18,23,8,2  
    同位素及放射线: Pm-143[265y] Pm-144[360y] Pm-145[17.7y] Pm-146[5.53y] Pm-147( β[2.62y]) Pm-148[5.37d] Pm-148m[41.3d] Pm-149[2.21d] Pm-151[1.18d]

    电子亲合和能: 0 KJ·mol-1
    第一电离能: 535 KJ·mol-1 第二电离能: 1052 KJ·mol-1 第三电离能: 0 KJ·mol-1
    单质密度: 6.475 g/cm3 单质熔点: 1042.0 单质沸点: 3000.0
    原子半径: 2.62 离子半径: 1.09(+3) 共价半径: 1.63
    常见化合物: 未知
      
    发现人: 马林斯、基格伦登宁、科里尔   时间: 1945   地点: 美国  
      
    名称由来:
    得名于希腊神话中的普罗米修斯(Prometheus)。  
    元素描述:
    原本产生于恒星里,地球上的钷有着多种起源。  
    元素来源:
    先天并不存在,产生于铀、钍和钚的裂变产物中。  
    元素用途:
    用作测量厚度仪器的射线源。

    在游戏天黑请闭眼中表示平民

    展开全文
  • 微软PM实习申请

    千次阅读 2012-12-10 16:09:03
    2012年夏天,有幸通过了微软的暑期实习生筛选,进入微软成为了一名PM实习生。以下是对整个实习申请过程的总结和回顾。希望可以对有兴趣的同学起到一定的参考作用。 微软的PM什么   PM这个词,充分...

    做自己想做的事鈥斘⑷鞵M实习申请经验

       2012年夏天,我有幸通过了微软的暑期实习生筛选,进入微软成为了一名PM实习生。以下是我对整个实习申请过程的总结和回顾。希望可以对有兴趣的同学起到一定的参考作用。

    微软的PM干什么

     

    PM这个词,充分体现了英语简写恼人的地方。它既可以是product manager(产品经理),也可以是project manager(项目经理),而微软的PM,又是另一种:program manager。于是,当你想去IT公司应聘PM职位,你就得不辞辛苦对各种各样的PM都做些了解。

    产品经理最主要的责任是负责产品的设计和运营,以腾讯、百度的PM为代表。项目经理最主要的责任是制定项目计划、跟进项目,以IBMPM为代表。那么,微软的program manager呢?

    想要了解一个职位的最好办法,当然是进去实习啦。但是作为一个还没有进入微软实习的准PM,我的看法只能基于自己读的资料,以及和面试官的交流,权当参考吧。

     

    首先推荐大家看一篇文章,这篇文章基本把微软PM的由来和负担的职责都介绍清楚了:

    http://www.cnblogs.com/xinz/archive/2011/11/07/2239150.html


    PM虽然带着一个“manager”字眼,但实际上,并不管理任何的人。所有的IT公司都避免让年轻PM承担人员管理的责任。PM所管理的,实际上是资源。简单来说,PM为了实现一个目标,需要设计出方案,然后积极组织资源,并且推进完成。整个过程中,PM需要保持团队平衡,使得项目顺利进行。

    对于一个产品或者一项产品功能来说,PM是用户和开发团队之间的桥梁。把握用户需求,并设计出解决方案,是PM最基本的职责。面试官介绍说,在微软,PM的职责是很灵活的,既有主要负责产品设计的feature PM,也有主要负责商务和推广的PM,还有主要负责项目管理的PMPM所负担的职责,跟他的资历、所在的部门以及组内人员构架都很有关系。比如,作为一个新的PM,在产品整体设计方面就不能参与太多,因为这需要大量经验。更多时候,PM新人的工作就是实现一些具体功能:为这些功能写specifications,并且完成它们。

    总的来看,PM需要负担的责任是多方面的,在一个项目中,开发和测试不管的事情,都需要由PM来管:激励团队士气,产品的设计、运营,系统设计,推进项目等等。而在微软,你在工作中具体需要承担什么样的责任,就由你所在部门和自身来决定。因此,要做PM,需要具备几个基本的素质:沟通、经验和灵感,当然一定的计算机知识也是非常重要的。

    看完以上这些对微软PM的介绍,算是对这个职位有点了解了吧。你可能会觉得,PM啥都得张罗,又没有真正的实权,岂不是到处遭人白眼?猜得没错……根据我在百度的实习经验,PM确实不是啥好干的活儿。有位在有道做PM的同学总结到:做PM是拿着卖白菜的钱,操着卖白粉的心。说得很好。所以,好好想想吧,没兴趣的话,就直接关闭网页咯。如果看完以上这些,你还锲而不舍的想要跳入PM这个火坑,那么恭喜你,你已经跨出第一步了,请继续往下看吧。

     

    什么样的条件能申微软PM

     

    先来看看,在微软的招聘通告上,对PM的要求是怎么写的吧:

    1. Pursuing a BS/MS or PhD degree inEngineering, Computer Science or related field

    2. 1-2 years experience programming inC++, Java or other computer programming languages preferred      3. Familiarity with managing complexproject schedules, solving complex problems, and nurturingcross-group collaboration

    4. Strong technical prowess, includingunderstanding of algorithms, systems architecture, and end-userexperience

    首先,你得是计算机、工程学等相关专业的本科生或硕士生,最好有1-2年的C++java编程经验。第二,你需要熟悉如何为项目制定计划、解决复杂问题以及安排小组之间的合作。第三,拥有较强的技术知识,包括算法、系统架构等。

    所以,总结一下,你得是一个学工科的硕士或者本科生,比如,计算机、电子等相关专业。最好有一定的编程基础。再者,有一定的项目经验和技术知识,同时,有较好的合作能力。

    如果你觉得自己满足这样的条件,就大胆的投递简历申请吧。申请地址很好记,在百度搜索中搜“joinms”,第一个结果就是微软的申请网站。

     

    如何准备面试和笔试?

     

    在你投递简历之后,运气不错,很快就收到了笔试或面试的邀请。那恭喜你啦,你一只脚已经踏进微软啦。接下来,开始好好准备吧。

    先说笔试,微软PM的笔试和开发用的是同一套题目,可以去网上找往年的题目瞄一眼,其实帮助不大,因为微软的笔试题目变化较大。主要考试内容,就是CC++以及算法的基础知识。个人认为,把《程序员面试宝典》、《数据结构与算法》两本书复习一遍,拿下笔试的机会还是很大的。

    笔试之后,会等一段时间才会接到面试通知,所以稍安勿燥。面试一旦开始,流程就很快了。

    首先要强调一点,微软PM的面试是英文的,可能有一部分是英文,也可能是全英文。在微软有很多老外,而交流又是PM最基本最重要的本领,所以英文口语一定要比较流利。如果想要申请微软PM,好好练习英语口语吧。当然啦,也没那么难,只要敢说,说得基本清楚就好啦。

    为了准备微软PM的面试,我到网上找到了很多面经,也向在微软做PM的师姐取经,最后进行了一些总结。微软PM的面试题目可以分为四类:你做过的东西、项目管理知识、产品设计和很少量的算法题。还有一些,就是闲聊啦。

     

    1. 你做过的东西

    微软PM的面试,很喜欢问你在学生时代做过的东西,你做过的实习、参与过的项目、组织过的活动,都可能被他们问到。所以,要做的第一项准备就是,拿起你的简历,将里面每一点经历都在脑海中回忆一遍,再用语言组织一遍,保证在问到你简历中的东西时,不会表现得一片茫然。

    举个例子,如果你做过某个实习,就会问到你在实习中做的事情:在公司里的责任,你怎么解决遇到的问题,有什么较大的挑战,具体做了什么项目,学到了什么等等。如果你参与了某个工程项目,会问你项目有关的问题:让你画该项目的模块结构图,你担任的角色是啥,项目解决了什么问题,你觉得项目的缺点是什么,可不可以改进等等。

    总之,对你简历中的东西进行全方面360度无死角的准备就没错啦。

     

    2. 项目管理知识

    这一类面试题呢,主要针对在项目管理过程中遇到的问题而展开。主要考察你的合作、交流以及应变的能力。

    比方说,如果项目要delay了,你怎么办?一个任务需要其他人的协助,别人不理你,你怎么办?组织活动,资金有限,时间有限,怎么办?

    如果你有在公司实习过或者组织过一些活动,你可以根据经验来回答这些题目,如果没有,那就大胆猜测啦。总之,表现得自信合作,而且有原则。

     

    3. 产品设计

    微软的产品设计题和其他互联网IT公司不同。在腾讯、百度的面试中,都针对互联网产品进行设计,比如SNS、移动产品等。而微软的产品设计,主要针对一些逻辑性比较强的普通产品。比如,小孩用的手机、电梯调度、酒店的钟、车库之类的东西。

    首先,你需要把握住用户群和用户的需求是什么,然后从需求出发进行设计。注意,思路要有逻辑性,表达要清晰。

    也许你会遇到一个developer(开发人员)来面你,他的要求会更严格,需要你设计一个更复杂的系统。当然,会跟你所学过的东西有一定的关联。比如我,在百度翻译做过实习,就要我设计一个监控翻译系统的系统,完全懵掉。还有一个同学,因为做过p2p,所以让他设计一个多人会议系统。这一类的题目,就比较难了,有一定的系统设计和项目开发经验的同学会更擅长。实在想不出来,就向面试官求助,寻求引导吧。

     

    4. 很少量的算法

    算法题目很简单也很少,每次面试有一道题目吧。一般是手写一道题目的代码。想来,经过面试的准备之后,应该问题不大。可以用一定测试用例来测试自己写的代码。

     

    5. 闲聊

    如果问了以上这些问题后,还有多余的时间,面试官会拉着你闲聊。聊什么呢?对自己的评价、性格的优势劣势、如何看待测试、对微软有什么看法、有没有团队合作精神、对微软PM的认识等等。各个方面的问题都可能聊到,放松的答就行。注意一点,这些问题可能是用英文聊的哦~


    准备面试的时候,认准这几个方面进行准备就好。不过有一点,虽然面试官可能会问到你准备过的题目,但是背答案是万万不可的,用一个词来形容下这种行为吧:amateur

     

    我的微软申请经历

     

    1000个应聘者,就有1000个不同的申请经历。我的这份经历很普通,但对于我来说,是非常难忘的回忆。下面和大家分享一下。

    我申请的是2012年微软暑期实习。今年暑期实习招的人比较多,而我又是明年的应届生,所以机会比较好。三月份微软开始宣传暑期实习招聘。3月底,赶在截止时间之前,我投递了简历。原以为等到4月中旬才会开始笔试,于是清明就跑到江苏悠闲去了。结果在悠闲的路上,就接到短信,邀请我参加4.7号的笔试。这就意味着,我肯定没时间准备笔试了。不管了,听天由命吧。

    4.7号的笔试,我们学校设置了考场,非常方便。那天下午,我带着一只笔跑到理教去考试,一个半小时就考完了,又带着笔颠颠儿的走回实验室,就跟什么事都没发生过一样。突然觉得,这才叫生活。

    之后,就开始等通知。就在“五一”的前一天晚上,收到邮件通知,邀请我5.4号去面试。哇!太棒了!正好利用“五一”的机会,好好准备吧。准备的内容就是上一章中提到的那些,我将重心放在了英语口语上。而让我郁闷的是,面试那天上午,居然轮到我在实验室组会上报告paper!干脆拿paper来练口语吧。于是在宿舍里,我站在电脑面前,手里握着一支笔,看着PPT,像模像样的用英文讲了起来。那几天准备英文口语的过程很有趣,有一天晚上,居然形成了整个宿舍用英语大讨论的开心场面。


    5.4号很快就到了,上午顺利讲好paper,就拿着简历去微软了。我们这一批是中午面试,除了时间比较让人郁闷,微软面试的组织是很棒的,比某T公司那大卖场式的招人方式好太多了。来面试的人,分成技术和PM两类。PM6个人,非常少。技术则包括开发和测试,混在一起面试。我们坐在一个很宽敞的休息室里等待,桌上有一些饮料食品可以自取。几个PM坐在一块儿,开始聊了起来。6个人里,一共有4个北邮的,北邮帮太强大了!其中一个同学是某知名创业网站的站长,而且拥有一副好嗓音,非常厉害~我估计他应该也拿到offer了。下午1点,我们被分别带到各自的面试官那里。面试开始了。

     

    第一面,面我的是Office的一个PM,非常和蔼,健谈。总的来说,我跟他聊得非常好。


    我先用英文做自己介绍。我做自我介绍就是讲简历,这个过程中,我会非常注意和面试官的互动。我会特意提醒到,哪里比较interesting,哪里比较challenging,有意识的引导面试官读我的简历,以及待会儿和我进行交流。

    我的简历中,最吸引人的部分,当然是在百度做过的产品经理实习。于是,面试官就着这个实习,问了许多相关的问题。比较有趣的几个问题是,百度翻译比起其他的翻译产品,好在哪里呢?还有,让我解释为什么百度翻译不花大力气做“网络释义”。

    之后,又聊到我做过的项目,让我画一下这个工程的设计图。又问了问这个项目的目标是什么。他好像兴趣不大。转到产品方面,聊我自己用过的产品,还让我试用了一下windows8,让我谈谈看法。在项目管理方面,他问到,如果dev不配合,怎么办呢?最后,还问了一个简单的二分搜索题,以及多态的概念。除此之外,就是各种闲聊啦。我聊得很放松,面试官也比较满意。他对我的交流能力表示了赞赏。

    第一面很快就结束了,面试官抱着电脑去面下一个人,而我还是呆在那个屋子里,等待第二个面试官。

     

    第二面,面试官是个developer,头发花白,神情严肃。看到他一头花白头发,我又默默感叹“搬砖”对人的伤害之大。再一次下定决心,以后绝不搬砖。


    他没让我做自我介绍,直接就开始聊:自己的优势劣势、对微软PM的认识等。当他问我,如果有个项目可能要delay了,怎么办。我的第一反应居然是,找mentor一起解决。现在想起来,真是愚蠢啊。虽然重要的事儿需要向mentor汇报,但是怎么能第一反应是求助于mentor呢,一点自主能力都没有了!总之,他对我这个问题的答案很不满意。

    然后,让我写了个链表逆序的程序,写得一片混乱。我真的做不来码农么,这么简单的题唉。最后,我们进入了一道很难的系统设计题目,给百度翻译设计一个系统监控系统。我完全没有思路,在他的多方面引导下,才答出了一些东西。回来之后,和室友讨论了一阵,她提醒到,我忽略了一个很重要的方面,监控系统需要监控server最基本的健康状况。比如,serverCPU使用率、内存占用率、进程健康状态这些。可以说,作为一个系统设计者,我是完全不合格的。还需要多多积累经验!

     

    5.4号这天,就安排了两面。接着就是回去等通知了。5.6号的下午,正在看the good wifefoxmail里突然弹出一封邮件,邀请我参加5.7号早上的终面。据说微软的规则是,拿到3个面试官中的2票就可以通过。看来第二个面试官那票是被否决了,不知道有没有不参加终面就拿到offer的同学。这时候,我已经有些激动了。微软,离我只有一步之遥了!

     

    5.7号的面试安排在早上8点半,太早了,不知道会不会困死。刚好还有一个认识的同学也要去面试,我们一大早就一起乘出租车去了。上次在一号楼面试,这次在二号楼,而且直接上office7,8层办公室等待。

    完全没有想到,我的最后一面这么轻松。一个年轻的面试官,性格极为开朗,而且是全中文面试,或者更准确的说,是全中文聊天。聊我在百度做过的项目、百度要不要加班,聊微软PM和其他PM有什么不同,聊如果developer提了什么不厚道的要求,该怎么处理,聊如果我负责给大家买饮料,用什么方案。他的问题都是即兴的,会挖掘得比较深,但没有故意刁难。而且他总是一副笑呵呵的样子,让我感觉很轻松。期间,我渴得不行,还麻烦他去帮我拿了一瓶水。看来,我的最后一面总是有好运,当时面百度也是,遇到了组里最nice、最和蔼的mentor

    面完之后,我回了实验室。很快就接到了同去的同学打来的诉苦电话,他是一个老外面的,全是系统设计的题目,被虐得很惨。不过,最后他也拿到offer了,可见面试官tough也没关系,你觉得你表现不好,并不代表你没有机会。


    当天晚上,微软就发offer了。这次拿到offer的同学很多,大家在群里讨论得很热烈。非常开心大家都能够有好的结果。至此,微软PM实习申请就告一个段落了。想起去年这个时候,找开发的暑期实习,连连受挫,心灰意冷之下,开始考虑转向PM方向发展。从犹豫不定,到积累知识找到感觉,再到百度那份珍贵的实习,最后到今天,我最深的体会就是:youdo whatever you want with your life!做自己想做的事,过潇洒的人生~

    5月底,我就会加入微软这个大家庭。而下一个目标,就是顺利完成实习并且转正啦。我也深知这次能进微软实习,有一定的运气,自己的实力的确有待提高,所以,继续加油吧!


     

    展开全文
  • PM8:30,还在加班!!!

    2014-03-31 17:26:57
    打了个冷颤,外面似乎很冷,还是空调开的太低了?立冬了,冬天也就是来到了,可是生活中还是没有感觉到如家里冬天来临的感觉,那冷嗖嗖的赛风,似乎是冬天吃起的号角,要天马行空的扑来,让你措手不及,可是南方的城市丝毫...

    天都黑了,周围也很静,只有我敲击键盘的声音,似乎破坏了这份难得的清静.穿过玻璃望去,外面黑呼呼的,只有自己的影像,在玻璃窗上呈现出来.

    我打了个冷颤,外面似乎很冷,还是空调开的太低了?立冬了,冬天也就是来到了,可是生活中还是没有感觉到如家里冬天来临的感觉,那冷嗖嗖的赛风,似乎是冬天吃起的号角,要天马行空的扑来,让你措手不及,可是南方的城市丝毫感觉不到这点,

    冰冷冷的只是,这座城市留给人的,水泥墙,水泥路,人与人之间的冷漠............

    其实对生活我也不知该要求什么,该如何去做,感觉进这个厂,前半年在技术和人际方面进步还是不小的,可是随着时间的推移,我渐渐的开始颓废起来,学不进去东西,不会给自己压力.一切都在平静的走着,没有一点激情,没有一点快感,平静的生活着,就像在走向老年一样,在静静的等......

    实际点想一想,从走出本校门到如今,我生活中接触到的人,技术方面没有一个让我佩服的,也许我所处的环境和所做过的公司有关系吧,眼界狭小,来到这个厂之后,感觉像碰到老朋友一样认识一位同行,可是又回台湾了,又离开这个厂了,之后很少有这方面的交流,没有了对象,我好象失去前行的动力,就让自己在大海上漫无目的漂,直动出现下一次风暴,让我航行的船给打烂,我想我才会有勇气重新走向挑站,走向新的生活.

    我会这样的做吗?不敢想象...........

    还是尽自己最大的努力去做目前最想做的事,以后的事以后再说吧.

    <script type=text/javascript charset=utf-8 src="http://static.bshare.cn/b/buttonLite.js#style=-1&uuid=&pophcol=3&lang=zh"></script> <script type=text/javascript charset=utf-8 src="http://static.bshare.cn/b/bshareC0.js"></script>
    阅读(458) | 评论(0) | 转发(0) |
    给主人留下些什么吧!~~
    评论热议
    展开全文
  • 浅谈PM

    千次阅读 2008-03-17 11:19:00
    随着PM在中国的 悄悄兴起,越来越多的PM开始在老总的授意下参与商务谈判,和销售们一起打单子,这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要 有多方面的知识,需要深度和广度,然而,最重要的仍然是...
    一.商务谈判
    

    1.作人的姿态
    作 人似乎跟商务谈判不太有关系,很多技术人员相信PM需要的是本事,是如何做好一个项目,而不是会搞好关系弄的四平八稳的人。随着PM在中国的 悄悄兴起,越来越多的PM开始在老总的授意下参与商务谈判,和销售们一起打单子,这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要 有多方面的知识,需要深度和广度,然而,最重要的仍然是作人。如何放下架子,降低作人的姿态,对从技术人员转型的PM们来说,是至关重要的。

    降 低作人的姿态需要从多个方面去实施,最主要应该记住:人不可貌相,更不可以地位衡量。很多公司为了保持公司形象,会统一叫员工打扮的好看 一点,看起来象个白领的样子。然而,老板多半是没有约束的。中国改革开放才二十年,很多有钱的老板实业家文化层次都不高,往往是当大学生们 只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时,他们已经在各地奔波,积累丰富的商业经验并对金钱,人生和社会的本质有了充分的认识, 形成了自己稳定的思维框架。这些人,很多都是穿着旧旧的衣服,戴着破破的手表,说话的时候经常会带上三字经,钻进上海的人堆里,搞不好你会 把他当成民工。因为到他们所处的社会地位,已经不需要任何华丽的外表来衬托自己的身份,他们有的是底气。对PM来说,这是个非常危险的挑战。 虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解,然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气,很多人谈 项目的时候看到民工或很俗气的表现不免会皱皱眉头,往往在皱眉头的时候就失去了项目,也就是失去了市场和金钱。PM必须作到能与每一个层次的 人交谈,尤其是看起来比自己层次要低的群体,哪怕是公司里扫地的阿姨。只有作到谦虚谨慎,不摆架子,尊重别人,才会得到别人的尊重,才有机 会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。

    2.丰富的知识面
    光尊重别人还不足以赢得项目,准确的说是赢得对方关键人物的 信赖。PM一般用不着陪客户喝酒吃饭,那是销售们的事情,但是PM和客户讨论问题可 能是最多的。讨论问题的时候就是机会,如何投其所好,是一大关键。金钱与美女依然是常规的敲门砖,然而这种傻瓜也知道的办法人人都会去做。 老板的关系也只是一个方面,如今的大老板,哪个没有关系?同等条件下PM凭什么去胜过别人一筹?

    我一个朋友(PM)打一个单子时,发现对 方对什么都不太感兴趣,费了很大力气也找不到突破口。对方这个人非常顺利,金钱地位美女样样不缺。他 花了好多天和对方交谈,以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎,如获至宝,回家花一个通宵 的时间在网络上搜索相关资料。第二天他根本不谈项目的事情,只跟对方大谈特谈哥白尼,布鲁诺,伽利略这些人的生平,整整吹了一天。对方点头 如捣蒜泥,态度和热情都来个一百八十度转弯,隔天他就拿到了单子。这是个经典的战例,谁能事先想到哥白尼会来帮助IT的人赚钱?这个PM靠的就 是博学和由博学引申出的敏锐的感觉抓住了机会,让客户产生共鸣。客户感觉他层次也很高,而且和自己有共通之处,信任度大大增强,把项目交给 他放心。如今这种例子在商务谈判中已经屡见不鲜了。对PM来说,并不要求在各个方面都很精通,那是不可能的事情,只要PM对一些流行的话题和天 文地理历史各方面的知识有个大概的了解,在需要的时候能尽快的掌握,才有机会创造机遇和把握机遇。

    3.强大的沟通能力
    胸中有万千墨 水却不知如何表达其实是比较少见的,但并非绝对没有。每个人的人生轨迹都有所不同,思维受环境的影响也各有差异。包括象我们目 前这个班级里的一些未来的MSE们,一定有比较内向或者不太爱表达自己观点的人,这些人比较被动,往往很难承担起谈判的重任。从今天开始,这类 人就必须重新学习如何说话,如何大声的争论。沟通,并不仅仅是大声说话,而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外, 沟通的能力与社会经验息息相关,与PM的见识联系紧密。在日常生活中,PM就要多留心,多思考,当别人想到某个层次的时候要争取比别人考虑的更 深。当然,也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情,在和客户交流的时候口若悬河的说一些不着边际的话。这种人,碰到不 懂,不太认真或者好奇心强的客户是有一定市场的;而有水平,负责任的客户往往会觉得这种人不可靠,一般不会把单子交给他。PM需要把握好这个 度,吹是肯定要吹的,只是吹牛的时候一定要有基础的去吹,对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见,挑选自己熟悉的方向合 理的进行发挥,适当的留上一两手,给对方高深莫测的感觉,效果最好。

    4.优秀的售前团队
    这个团队一般是由总经理发起并组建的,通常 不指定PMP,对团队的成员如SALES,PM,SA,ENGINEER们的团队合作提出了比较高的要求。一般公司在 接下一个单子进行到一定程度的时候,PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常 多,销售的任务是拿下单子,我听到的销售们说的最多的就是“没问题”或者“NO PROBLEM”,但是当我听到客户的要求和销售的回答时我总是心惊 肉跳,很不自然。销售是非常辛苦的,为了建立客户关系,尤其是空白的市场是很不容易的,往往为了一个单子会牺牲非常多。在这种情况下,和销 售进行协调自然而然的又落到了PM的头上。在销售和客户做承诺之前,PM要主动的跟销售交流,提供粗略的总体设计框架和技术难关以及能考虑出的 工作量,而不是等出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候,PM要根据团队里每个人的素质和任务进行因人置宜的信息传 递。优秀的售前团队合作是接单的重要保障。

    在商务谈判的实际操作中,存在着各式各样的问题,PM的职责和要求绝非以上几点所能描述详尽。根 据环境,政策,人文,关系等各方面的不同情 况,PM的不同成长经历,每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定,这是PM成为PM的第一道关,也是最重要的一关。 接不到单子,PM将失去存在的意义。与销售有所不同,PM在该阶段的任务除了接单,还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责 人建立良好的客户关系,以便在项目实施时充分调动资源。

    二.启动阶段

    1.项目的一些基本概念
    项 目三要素有多种版本,各不相同。实际操作中多分为范围,成本与进度,其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文 档统称为递交件。谈判的时候一定要确立递交件的标准和要求,也就是范围。尽管商战的时候不可避免的客户会不断提高标准和要求,而承诺的款项 却不会有一分钱的增加。但是这个标准对每个公司来说都有一个底线,一旦超过了这个底线,那项目就肯定是亏的。除非是为了二期有利可图或者是 为了搞好关系,否则范围超过底线的时候情愿不做,再厉害的PM在这种情况下也是无能为力。建立范围需要的就是PM的多年的实战经验,在大大小小 的项目中用血泪换来的一些体会。在这个时候,很能体现PM与技术人员的区别。成本就是客户答应付的款项,与我们的投入成本并不是一回事情。进 度就不用多描述了。

    项目如何成功?也有一些关键的因素。个人的理解也不尽相同,通常包括以下几个方面:界定工作目标及工作任务;老板或高 层的支持;优秀的PM和 开发团队;充足的资源;良好的沟通;对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时 会有很多项目,可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避 免的会发生资源争夺战,摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度,如果PM平时在公司与同事相处的好往往能 使很多别人看起来很棘手的问题迎刃而解。相反,一个不会作人的PM由于人缘差,即使高层强压别的部门或团队配合,别人也会能拖就拖,延缓项目 的进度和质量。有时候,这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力 尽,要PM去主动要求客户配合是很吃力的事情。然而,这个时候,越是困难,越是觉得累,越是要去主动。客户往往也不是特别的积极,主动与客户 联系沟通和测试能及早发现问题。从风险控制的角度来说,问题发现的越早,风险越小,损失也就越小。积极的态度可以带动客户的积极性,在项目 完工的时候,客户对你的感激往往是难以用语言描述的,这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候,新客户 自然会找你的老客户了解情况,这时老客户随意的一句话顶的上你很费心的十句。

    项目具有商业行为的几个重要特征,有消费源,有参与者,有成功关键因素,有财务目标,有风险。

    2.启动阶段的主要任务
    根 据PMI的解释,接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据,确立尽可能详 细的需求,进一步确立详细的项目范围,预估资源,确立其他方案并获得进入下一阶段的批准。在这个阶段,随着需求分析的深入,PM也开始在公司 内部进行人员挑选和资源争夺,着手组建自己的项目团队。项目即将进入计划阶段。
    在收集完数据之后,PM要和客户开始明确项目的大小,成本,规格,期限等重要特征并将其写入合同文本,同时准备内部的包括预算,衡量标准等文 档,建立项目的评估标准。接下来就是需求分析。由于专业的原因,我们这里仅讨论软件工程项目的需求分析(以下简称需求分析)。

    需 求分析的主要参与人员有PM,总体架构设计师,系统分析员,熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队,我们叫做前期团 队。随着需求分析的逐步深入,新的团队成员不断加入,启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说,需求分析直接决定了 项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊,无法体现客户真正的需求。前期团队要根据 自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化,就要求按照他的思维去定一些明显错误的需求。这个时候团队 成员要耐心和客户举事实,谈经验,讲道理,用图形或模型等直观的方式将需求描述出来,比如常见的数据流图等。所以说,争论再所难免,客户有 时候会吹胡子瞪眼睛拍桌子甚至会说“这个东西不要你们做了”之类的话。PM此时除了要亲身参与需求分析综合整理文档之外,还要处理好团队成员 与客户的关系,确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员,这个度还是很容易控制的。

    对快速开发和叠代开发来说, 需求和实现往往是同步进行,开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很 合算的做法,时下流行的极限编程就是针对这方面建立的思维模式。然而,大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异,那 么市场上就只有产品而没有项目了。所以,大中型项目的需求要认真仔细的去做。我们要讨论一个问题,究竟应该在需求分析和总体设计上花费多少 时间?我们熟悉的瀑布开发模式基本上分需求分析,总体设计,软件开发,测试等几个阶段,然而究竟应该在前两个阶段上花多少时间却没有定论。 实际项目操作的例子表明,分析设计的时间越长,需求设计做的越详细,测试的时间就越短,返工率越低,风险也越小,成本越容易得到控制。而需 求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大,到了项目后期和测试阶段一些潜伏期比较长但是破坏作 用比较大的问题就会凸显出来,造成返工,延长测试时间。所以与其把问题堆积到紧张的项目后期,不如把时间多花点到需求分析和总体设计上。基 础夯实了,金字塔就容易造了。

    在日本公司打工的程序员们可能都知道,小日本的软件规范非常厉害,他们花在需求分析和总体设计上的时间通常 在40%到50%左右,远远超过国内软 件项目的实施,效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断,确立什么样的条件,换言之就是把什么时候该如何写 (if...else)语句都帮程序员定好了。在这样的软件规范下,程序员更象是装配流水线上的工人,对一个模块或技术熟悉到一定程序就变成了完全的重 复性劳动。所以在日本和欧美经常会有程序员是低级工作一说,很多人不明就里,对国内程序员也照搬,对国内的程序员来说是很不公平的。在国 内,只会照抄别人代码,一点都不懂创新,凡事依靠别人,快下班就盯着表看的程序员是不少,这种人一般很难有什么前途。但是,优秀的不断进取 的程序员也很多。由于国内没有象CMM这样的软件规范或者很少,所以这类优秀的程序员不少都是干着系统分析员甚至PM的活,拿着程序员的工资。这 类程序员虽然在起步时会吃很多亏,而且是主动找亏吃,然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行 商务谈判的时候,前者还在各个公司里频繁跳槽,跳来跳去都不满意。有些扯开了,回到我们的话题。日本的软件规范与CMM有惊人的相似,其中至少 有35%以上都是几乎一模一样的。最近经济不景气,东京倒闭了160家软件公司,这个数字是今年6月份的,还在不断增加。这些公司纷纷抢滩上海,招 收技术人员。如果去这样的公司应聘就要考虑清楚了,进去可以学到他们的规范和质量控制,可是要想从程序员成为系统分析员或PM,比登天还难。 往往一个程序员进去干了好几年,对自己的那一块熟的不得了,而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4(华为印度研究所已经通 过CMM4),对在华为工作的程序员们来说可谓福祸难料。当然,已经作到PM或QA或者热爱CODING的朋友例外。
    需求分析本身也存在着时间分 配的问题。第一遍需求分析花的时间会最长,分析员们在客户的各个部门之间几乎把腿都跑断,把口水说干,就是为了 确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字,不合格的打回重做。反馈表随之将提交给客户,第二遍第三遍等等等等接踵而 来,与客户反复讨论和磋商,反复提交文档和表格,目的只有一个,明确需求。当PM最终合并了所有文档并确立需求之后,最终生成的需求文档将提 交给客户的各部门负责人签字。这些文档将作为合同的附件添加,以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是, 客户并非都是蛮不讲理,但是说实话,颇有无奈,国内目前的项目大多数客户为了不让自己的钱白花,经常变着法子提需求。在启动阶段明确需求并 签字,无论最终情况如何,一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。

    详尽的需求分析有一个额外的好处就是 对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候,这种大项目在 签单时双方都没有绝对把握保证可以出成果,一旦在需求分析阶段发现难以逾越的技术难关,就会放弃项目。典型的例子就是NMD洲际导弹防御系统。 上世纪八十年代初美国搞星球大战计划,拖跨了苏联。大家对那段历史有些含糊,很多人认为苏联人上了美国的当。其实并不完全如此,苏联人的情 报机构无孔不入,并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析,前后耗资数亿美圆,耗时两年,仅仅是做需 求分析,终于发现存在着在当时技术上无法达到的高度,随后项目被放弃。

    3.项目启动
    项目启动要确定项目计划,与客户一起实施第一次 项目审核,确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会, 一天开三到四个会议是很正常的事情。这些会议有与客户的会议,与下包厂商的,有团队的,有公司高层的。团队的会议主要是建立正式的团队,提 供团队成员的角色和职责,提供绩效管理方法,向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确 立正式的交流渠道,项目综合描述,让项目参与人员相互了解,建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小,电 话多少部,所有人的联系方式等等都要在会议上确立,并做会议记录。这都是些非常琐碎的事情,听起来婆婆***,却是非常必要,缺一不可。大 概就是所谓三军未动,粮草先行吧。
    这时候,作为公司高层,应该向全公司发表申明,正式给PM发布项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义,但是对提高 PM本人的士气和责任感是有很大助力的。

    三.计划阶段

    1.定义结构分工结构图(WBS)
    启 动阶段结束后,项目进入计划阶段,也就正式进入实施。这里概念可能有些不太对头,其实是翻译的缘故,反正大家明白意思就行,不用拘泥于字 面。WBS是一组要提交的项目元素,用来组织定义项目的总体范围,具体包括从工作内容,资源,成本角度考虑项目范围;建立一套系统所需要的分层 工作结构;把项目分解成易于管理的几个细目,这概念有些模糊,其实跟资源管理器里分目录是一回事情。可以说,WBS是计划阶段的核心。WBS会详 细的分到递交件,包括给自己人用的项目使用的过程文件,给客户用的模块和说明文档,完成每个细目的标准以及如何把这些细目的责任分配到具体 的个人。WBS有缩进式和树状式,我这里也没办法画图,大家参考一些项目管理的书籍,里面有详细介绍。我整个文章只挑我觉得需要注意的地方,如 非必要,对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平,最下面的细目叫做工作包,分包的依据是个人的责任和可信 度,也就是说到每个人头上的任务是否能落实,是否有把握完成;还有就是准备对项目进行控制的程度,程度越深,WBS树也就越深。由于WBS是实用 性的东西,根据个人理解也不一样,所以一个项目可能会有几个正确的WBS,看PM的需要和最适合当前团队状态的进行选择。

    WBS的定义还 是很麻烦的。PM要召开团队进行讨论,向成员提供与项目相关的所有详细资料,并把WBS树分解到二层三层。然后要花上一段时间让成员 进行头脑风暴式(BRAINING STORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准。在头脑风暴式思考时,会有很激烈的争 论,PM要协调关系,调节气氛,从自己能考虑到的各个角度旁推侧敲,提示成员的思维角度和方向并加以总结。尽管很麻烦,制订WBS仍然是非常值得 的。如同需求分析一样,WBS准备的越充分,编码的进度越快。

    2.风险管理
    既然是商业行为,那么项目的风险必然存在,相信阅读这个 帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决,有些风险则大大损害 利益。不论什么样的风险,能避免尽量避免,所以有必要对风险进行管理。由于风险的不可预知性,风险管理难度很大,概念也很难讲清楚,只能从 一些可行的角度去分析,进行管理。

    首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议,这个会议面向公司,高层,跨部门的有 经验的人都将参加。然后审核由项目小组 生成的风险清单并与重要成员进行风险沟通,检查一些重要的风险源如WBS,成本(时间)预估,人员计划,采购管理等等。最后就要用到PM本身在以 前类似项目中得到的经验教训。

    识别之后要进行分析。我们可以进行粗略的量化分析(精确分析是不可能的事情)。有经验的人可以一起参加讨 论,把提交出来的风险进行分类。首 先按发生的可能性分,一般分成高,中,低三个级别,虽然很勉强,但是好歹也有个量化了;然后按耗去的成本分,也是高,中,低三级。我们可以 把这两种类别的三个级别进行组合,碰到可能性也高,成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成 本,否则一旦亏起来不是亏一点点,有可能赔的很厉害。高和中,中和中的搭配都是属于高风险,中和低,低和低搭配属于低,高和低搭配属于中。

    针 对出现的可能性,需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式,只能尽其所能的避免。有几种方法可以考虑,第一 种是将风险纳入项目管理计划并指定负责人,由外部人员定期检查项目风险,一旦风险发生,执行风险管理计划;第二种是保险,这种属于风险转 嫁;第三种方式有点奸,不过最保险,就是把客户拖下水,让他们一起参与风险管理,呵呵,到时候就好说话了:)
    风险管理作为项目计划之后,PM需要更新WBS,修改日程计划和更新风险管理计划。
    风险预留通常是成本的8%。

    3.预估
    预估是从量化的角度对项目进行评估,主要包括工作量,任务期限,人力,设备,材料,成本等,要注意预估不是财务策略或报价。
    预估其实并不是一次性工作,在整个项目过程中,预估始终需要。预估似乎没什么特别需要提的地方,每个PM接到项目的时候自然会有预估,在项目 发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底,安排计划时不至于毫无头绪。

    4.进度计划
    进度计划就是一个模块或功能要写多长时间,PM安排个日期,设立里程碑,叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说,合理的安 排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说,进度计划毫无疑问是噩梦。

    显 示进度计划一般有先后顺序图,甘特图和里程碑图表。上回邵卫老师讲课,推荐的工具是m$的PROJECT,这个工具我还不会用,因为没时间去摸索。 我的头倒是用的很溜了,近一个月来他就用这个PROJECT画了一个又一个的里程碑图,不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST,效果上来看,因为有强大的时间压力,效率上比之前确实要提高不少,可是我们也只能结结巴巴的赶完进度。由于TEAM里人少,我们都是一个 人做几个人的活。我每天早晨六点多出门,经过将近两小时颠簸,八点多点已经坐在位子上,中午吃15分钟的饭,干到晚上八点下班,到家吃完饭往 往已经11点了。一个多月我从来没吃过早饭,没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能,开发更多的 模块,但是对我们的情绪也是有很大的影响。所以说,项目里程碑是一把双刃剑,合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级 衰落会给项目后期的开发带来难以估计的影响,进度将会大大延缓。关于PM和团队的问题我们后面会讲到,这里我先祥林嫂一把,然后跳过。

    里程碑图表的特征是任务,成员和时间,任务和成员用文字标志,时间用数字描述并辅助以图线跨度,象阶梯一样非常形象,一目了然。管理起来非 常方便,完了的打个钩就可以了。

    网 络逻辑图是表示任务和逻辑关系的示意图,可以用先后次序表示,也可以用关键路径表示。其实把各个活动划分为1,2,3,4等阶段,每个阶段包 括小活动1.1,1.2,2.1,2.2,2.3,2.4,3.1,3.2,3.3,4.1,4.2等,日程计划也分四种,一般只提到从前向后和从后向前 两种。从前向后的概念 就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口,我们打个比方:2阶段指向3阶段,那么2阶段里 的4个子阶段也都指向3。假设2.1结束时间为1月12日,2.2结束时间为1月22日,2.3结束时间为1月15日,2.4结束时间为1月20日,那 么,2阶段中最晚 的结束时间是2.2的1月22日,所以在3阶段中的3个子阶段3.1,3.2,3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去 推吧, 我就不举了,刚才几个123打的我累死了:)

    项目经常需要调整进度。在不改变项目范围的情况下,调整进度有几种方法:利用快速跟 踪手段来改变任务间的关系;将串行的任务改成并行;改变 工作方法(可能改变WBS);改变日期限制,使关键路径上的任务开始或结束的更早。虽然方法多样化,在我看来只有一条,就是拼命的压榨程序员的 劳动力。如何压榨,还是个技巧。如前面所分析的,需求分析恨不得多分点时间给它,压需求是不太可能;测试阶段后期接近完工,罗里巴唆的事情 一大堆,忙都忙不完,那时候PM一门心思提前/按时完工,好收钱,压那段时间似乎也不太可能。说来残酷,最能压的还是CODING,编码阶段往往是压 缩重点,总之大家埋头苦干就是了,大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情,相信不少人都有很深的体会,这里伤心事情也就不 提了。只是我总结一下,让未来的PM们有压榨后来人的依据,呵呵。测试前期也可以适当的压一压,那时候人刚完工,都比较懒散。国内一般企业规 模都不大,没有专门的质量控制部门,所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。 在日本和CMM实施的公司里,编码压缩是很容易实现的事情,因为那些程序员真的是技能熟练的装配工人,压起来方便的很。他们这样培养人的目的或 许就是为了压缩吧?!

    四.控制和执行阶段

    1.软件开发
    实在没什么好说的,也是大 家最不愿意谈的,平时在公司里谈的已经够多的了,还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档 管理制度。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员,因为我碰到过几 个。我爱人公司里也有一个,他们的一套产品核心代码就是这个人写的,4年过去了,周边代码换了好几茬,核心算法始终没换过,可惜这小子跟了李 洪痔,如今已经不知所踪了。但是他的代码似乎也要有点注释的,没有注释过段时间再天才的程序员也不能保证他是最有记忆力的。而且,对一个项 目的编码来说,靠一两个人打天下如今是不可能了。别人的公司都是团队,两人智慧胜一人,这头还在靠一个天才支撑门面,实际上市场可就别人抢 了去,那时候再天才也没用了。编码的时候讲究技术公开,程序员不要藏着掖着,对大家没好处,PM要想办法调动大家创新思维的积极性,营造良好 的技术讨论氛围,碰到技术难关的时候就容易攻破了。

    有个问题需要单独对还没有PM觉悟的程序员说,其实是在调研的时候就定了的,就是使用 什么样的开发工具。没有经验的程序员往往会拿着C++或者 JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个,他们关心的是使用什么样的工具能尽快的达到目 的。管你什么C++,DELPHI,PB还是JAVA,只要能做的出来,VFP都可以用。我举这个例子并非说不看中工具,而是提醒想转型为PM的程序员, 第一要 把工具当作工具,而不要被工具套进去,钻研一些一辈子都用不上的技术;第二要掌握的并非是单独的一个工具,而是流行的程序设计的思想,以及 在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维,才有可能转为PM,否则一辈子都是技术工人,最多就是个技术总监。

    2.变更
    对 任何项目,变更无可避免,无从逃避,只能去积极应对,这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说,基准文件定 义的范围越详细清晰,用户跟PM扯皮的幌子就越少。而需求没做好,基准文件里的范围含糊不清,被客户抓住空子搞你一下是非常头疼的事情,往往 要付出无谓的牺牲,有时候甚至非常火大。

    需求做的好,文档清晰又有客户签字,那么后期客户提出的变更就超出了合同的范围,需要另外收费。 这个时候千万不能手软,并非要刻意赚取客户 的钱财,而是不能养成客户经常变更的习惯,否则后患无穷,维护的成本会让PM吃不消。在客户提出变更请求时,要建立变更申请登记表和变更申请 表,并让客户签字。当然,有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要 卖面子,但是也别卖的太干脆,不要让他们得到的太容易。

    需求做的不好,客户抓住漏洞或者非常不讲道理,麻烦就大了。有时候争论会很厉害, 到非常白热化的地步,PM与客户代表几乎沟通不了。PM在客户 关系和短期利益两方面难以取舍,一般都是向客户妥协,最终形成恶性循环。这种情况非常难办。一般这种情况都是到了项目后期,做重大的更改几 乎是不可能的事情,如果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞的定,可以透过对方高层把事情压住。然而由于已经到后期,客户 代表不会轻易更换,对方这次没有改成,必然心怀不满,下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚,都是很让PM伤脑筋的事情,这 方面目前还没有什么好的解决方法,所以尽可能的做好需求比什么都重要。相对需求来说,什么WBS,风险管理,计划进度都是扯淡,需求做好了,一 帆风顺。还有一种办法就是装可怜,要装的非常的象,在对方的领导面前装,而且不能让人看出是装的样子,要让你自己都觉得你自己是真的可怜, 那么就算这次客户硬是要求改了,下回他也必然不好意思再叫你改。其实人心都是肉长的,如果可能的话,我还是不赞同使用一些手段的,但是有时 候客户非常难以在短时间打动而工期又将接近,这种情况下就要靠PM耍一些手段了。各人有各人的方式,八仙过海,各显神通吧。

    PM在变更管理中需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。

    3.质量控制
    大 公司有质量管理部门(QA),QA的成员基本上都是由非常有经验的PM转型过来的老狐狸,是老总接班人的有力争夺者。一个QA会管理多个项目,有 时候甚至会亲身参与。PM和QA有些象猫和老鼠,不停的通过报表传递一些心照不宣的假数字。QA对PM的工作最终是有评定的:A级表示总体在控制 下;B级表示当前在控制下;C级表示有显著问题;D级表示有重大问题。如果PM得了个D,那可不太妙,不但世界级的QA会每个月要收报告,地区QA会 一个星期找来面谈一次,训一顿。得到A的PM是很逍遥的,基本上不会有人来过问。在没有QA的公司,质量控制只能由经过授权的团队成员进行,效果 就要差的多了。
    质量管理贯穿整个项目周期,详细的可以参见CMM。

    4.成本管理
    PM经常通过控制进度和预估来控制成本。 PM必须经常问自己,项目已经到了什么阶段?完成了多少?花费了多少?完成时成本是多少?挣值法的术语 不少,象BCWS,BCWP,ACWP,但是关系比较简单,大家参阅一下相关资料,这里不再羸述。总之,PM要管理好成本,注意节约,但并非是拼命剥削程 序员,该花的还是要花。

    五.结束阶段

    1.项目结束
    项目结束时,PM要将最终系统方案提交给用户,完成项目所有的提交件,收集项目全部信息并结束项目,完成或终止合约,签署项目结束的相关文件。

    项 目结束意味着可以收钱了。PM辛苦了那么多,终于可以高兴一下了,收到最后一笔款项,意味着递交件的移交和团队的解散,项目也转入维护阶 段。不过收钱未必代表着赚钱,要看项目是否按时完工。一般来说,提前完工的项目很少,但是能赚大钱;按时完工的赚小钱;延期的要赔钱。一个 人首次承担PM,如果没有人带,多半会失败。失败没什么,所有的PM(注意是所有,不是几乎所有)都失败过,然而失败会成为教训和经验,推动你 继续前行。在美国,每年至少有40%的项目无法实施被搁浅。只有在项目中和生活中不断磨练,培养自身素质和作人的基本准则,才能成为赚大钱的 PM。

    2.项目完工会议
    项目结束时,依然要开会,不过少多了。一般跟客户要开一个,主要是确定所有的提交件都已经被接收,对突出的个体进行表扬,对外宣传成功案 例,标志并记录项目的正式结束。这时候开会很轻松,目的也很明确,做完了大家好聚好散,或者以后有机会再合作。
    团 队要解散,内部会议肯定是要开的。也没什么好废话的,该表扬就表扬,该发多少奖金就发多少奖金,毕竟大家都累死累活的干了那么长时间。项 目结束请客户出去泡温泉时PM们千万别忘记了辛苦为你工作的程序员和工程师们,当然,如果他们不愿意看到你的脸那么你就折现发到他们的存折上去,正好让他 们回家好好休息休息。这样下一个项目需要他们 的时候他们才会为你卖命。说出来奖金发出去似乎你损失了,其实你赚大了。

    3.客户满意度
    形 势也好,历史记录也好,尽管项目结束的时候客户满意度PM心中已经有底了,但是还是有必要向客户各个层次的项目代表发一张信息反馈表,收回 的信息将反应客户的满意度。其实真正体现客户满意度的地方有很多。第一就是付钱付的快,如果客户不满意,一分钱藏在他牙缝里你也很难抠出 来;第二就是二期,二期非常非常重要,因为这里已经是属于一种无销售成本的项目,又有一期的经验,可以说二期的钱是最好赚的。这中间的感 觉,只有经历过的人才明白。

    六.团队管理

    1.建立团队
    挑选人材依然是PM头疼的一个大问题,有时候一个在别的项目里很优秀的人材,挖过来未必能适应。所以,PM还是要拓展知识面,培养自己的敏锐 度,因人置宜,才能挑选对自己项目有帮助的人材,才能真正对项目起作用。

    2.核心程序员
    任 何项目都有核心程序员。核心程序员背负着很重的责任,平时要和普通程序员一样没日没夜的加班,碰到重大的技术难关更是整个人扑在电脑上, 熬上几个通宵是家常便饭。常有人抱怨程序员工资高,真想请这些人来尝试一下程序员的工作,看看他们付出的精力是否配那份工资。前面说过的, 中国的程序员不同于日本和欧美,他们很多人参与了系统分析和建模,对脚踏实地工作的程序员来说,这份工资实在是委屈了。看看行业里努力工作 的程序员们,有几个不是头发花白,高度近视,未老先衰的?上星期五晚上我加班到10点,隔壁公司的一个技术总监特意留下来跟我说:“我们这种 人,前半生拿命去换钱,后半生拿钱来买命!所以,工作的时候一定要注意劳逸结合!”道理我并非不懂,我也不想透支自己的身体,但是我有选择么?

    PM 要特别注意爱护核心程序员,尤其是他们的生活困难和精神状况,有时候,他们耍性子或者不合作PM要妥协,要从自己身上找原因。其实在国内, 我还没碰到过敢这么做的程序员。相对PM来说,程序员是绝对的弱势群体,没有任何发言权,几乎可以说PM想怎么做,想怎么改,程序员就要付出一 切代价去达到目标。

    3.奖励与惩罚
    奖励是不用说的了,相信所有阅读我这篇文章的PM,未来的PM,程序员和未来的程序员们都知道如 何去做,这里只说惩罚。惩罚似乎很不好办,其实 对PM来说再简单不过。一个程序员把模块做砸了,骂,扣工资,开除都不顶用,在项目没完成之前不是追究责任的时候。一个优秀的PM应该给他一个 机会,当作没事一样让他去做别的事情,把他做砸的事情交给别人去做,就是对他最大的惩罚。这样既能激励他上进又不会让他尴尬,他会感激你一 辈子,因为你给了他一次机会。而PM挑选这个人进团队并给予他责任,他没有完成,PM本身就有责任,应该自我检讨。

    4.管理冲突
    无 论团队里的成员相互之间很熟悉还是不熟悉,冲突再所难免。在发生冲突的时候PM要牢记以公开,公正的方式处理冲突,不能因为其中之一是自己 的小姨子就干掉另一方;处理事情的时候必须对事不对人。有时候,成员与PM之间也会有冲突,一般情况下都可以几乎肯定是PM的责任,因为很少有 成员敢吃豹子胆来反抗自己的顶头上司。这时候PM除了要及时的做自我检讨之外,要有宽广的心胸。绝对不可以利用职权打击与自己有矛盾的成员, 否则团队里所有成员都会心寒,项目的质量将会大打折扣。如果他确实不对,也要忍住,等项目完了慢慢收拾他不迟。PM的心胸还表现在不能嫉贤妒 能上。当公司高层越级表扬团队某成员时,你应该高兴和光荣,而不是阴险的想着下次如何把这份光环戴到自己的头上。实际上在国内的很多PM都是这么做的,邀 功的时候全是他的,有了责任都在下面。这种PM永远做不大,迟早会被淘汰。

    5.承担责任
    项目是有风险的,肯定会有失败的部分甚至整 个项目失败。虽然说每个人都在WBS里定下了责任,在项目里程碑里都有任务。但是当整个项目危机来临 的时候,PM要勇于站出来,承担起全部的责任。这是做人的方式,也能让你赢得团队所有成员的尊敬和爱戴。往往在这个时候我们才能体会到什么叫 团队合作精神,就是大家齐心合力,共渡难关。

    6.资源争夺
    前面提到过,资源有限,如何争夺而不伤和气是对PM的另一个挑战。因为整 个公司是一个大团队,内耗的厉害对PM没有好处。当然,摆平各路神仙是 不可能的。但是一个健康的公司必然有健康的管理制度和优秀的成员。物以类聚,人以群分,PM应该在公司里主动结交志气相投的朋友,在拿到项目 时这些朋友会给你很大的帮助,当然,在这些朋友需要你帮助的时候你也应该懂得怎么做。如果你性子很怪,很难找到脾气相近的朋友,没关系,交 几个酒肉朋友也不错。我们公司数据统计,一个人在公司的人缘和他在公司请客吃饭的次数成正比。PM一定要尽心尽力的为公司打算,这样在需要高 层支持的时候才会获得鼎立相助,而总是为自己打小算盘的PM是不长久的,总会被别人看穿的。

    后记:写到这里实在写不动了,控 制阶段的合约管理和项目跟踪没有写进去,一方面我不熟悉,另一方面让大家自己去做一些思索。其实前天我就在 构思这篇文章了,本来还想把CMM也写一篇的,如今看来太高估自己的能力了,时间实在是不允许。抬头一看,东方已露鱼肚白,外面隐约传来麻雀的 嬉叫声。今天我还要去跟人谈祖房子的事情,明天还要上课,星期一开始又要没日没夜的加班,多想睡个懒觉呀!

     

    文章来源: 网友推荐
    发布时间:2005-4-12 
    项目管理者联盟[mypm.net]

     
    展开全文
  • 有设备放在家里,要做一系列复杂的内网穿透,把内网暴露在公网环境中才能在外面登录设备 有设备放在公司,复杂的网络环境无法做到内网穿透 有设备放在用户厂房,无法控制网络条件,每次出问题都要上门服务 有大一堆...
  • PM Related Topic 2

    2013-10-25 13:26:43
    的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么? 应该用。ClearQuest太复杂,的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么? 不要用Word写测试用例(Test Case)。应该用一个专门的系
  • 浅谈PM(项目管理)

    千次阅读 2014-10-19 20:28:43
    浅谈PM(项目管理) (2009-04-22 20:44:34) 转载▼ 标签: 项目管理 风险 软件开发 满意度 it 分类: Erp项目管理 一.商务谈判   1.作人的姿态 作人似乎跟商务谈判不...
  • 2013校园招聘——微软PM面试经历

    千次阅读 2012-11-21 19:46:44
    今天就问HR说为什么这么晚才面试,HR说,因为PM的人都比较忙,时间协调起来很麻烦。不过HR又说,PM很重视这次招聘,光是内部的协调会就开了好几次,囧.... 废话不多说,上干货。我们面试的制度是这样的,上午十一点...
  • 本周三一大早微软通知了PM实习生的offer,兴奋之余想静下来梳理下这一路的经历,留给自己也分享给有需要的人。 为何选择PM PM全称是product manager或者project manager,不同的公司可能会不一样,个人理解这两种有...
  • 产品经理(PM)职责介绍

    千次阅读 2008-04-12 08:53:00
    产品经理(PM)职责介绍2007年04月29日 星期日 下午 04:22 记得有一家大型的知名快速流转消费品企业,由于品牌扩张需要大量的专业职业经理人加盟。其中之一便是大量招聘产品经理。但当一些优秀的产品经理岗位的应聘...
  • React服务端渲染+pm2自动化部署

    千次阅读 2018-07-30 18:02:56
    本文是直接着手SSR部分的并通过实战讲述自己遇到的一些问题和方案,需要大家有一定的React,node和webpack基础能力。skr,skr。 服务端渲染 Server Slide ...为什么要用SSR? 首先我们需要知道SSR对于SPA...
  • 今天北京雾霾爆表,拿空气堡在外面测试,达到600多,然后在新风风口测试,差不多60到80。可以得到效率只有85%到90%左右,这和销售说的数值差不多,肯定达不到手册上写的99%,那是实验值,骗人的。 但是,家里的空气...
  • 数据说明 kaggle要求 预测思路 相關 reference 可以參考: 报告题 1. 不同学习率收敛情况 2. 减少feature (只取后5h) 3. 减少feature (只取PM2.5) 4. 调整改进
  • 很高兴宣布推出一本名《 人类可读杂志》的新编程杂志。 多年来,这一直是的梦想,而且,由于我们成功地发行了晨报的编码杯,现在它已成为现实。 该杂志秉承时事通讯的精神,汇集了素质的编程专家,深入...
  • [屌丝PM]设计心理学——科技超载

    千次阅读 2014-03-31 16:47:49
    今天,要和大家讲的是科技技术迅猛发展带来的一个负面效应,将这种负面效应称作“科技超载”。和日常交规一样,科技一旦超载上路,也会面临罚单,而这个罚单恰恰就是消费者开给设计人员的。 什么是...
  • 前段时间,在修订《淘宝十年产品事》一书,翻到当时收集的一些前辈的观点,发现依然很有启发 ,分享一下。言论的时间是2011~2012年间,当时,和几位同事在负责阿里产品经理的培养事宜,所...
  • 建设高效团队的七十五条原则(PM必读) 1. 你们的项目组使用源代码管理工具了么?应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么?应该用...
  • 为什么产品经理总被吐槽是”水货

    千次阅读 2019-01-29 18:23:24
    最近年底了,总参加各种聚餐...空降的产品经理就是部门缺人,从外面社招的,校招就不提了,基本上校招来的大家也不会抱太期望。空降的产品基本上十个有八个会被吐槽水,如果是转行的那种,比如本来做BI产品转化做...
  • 上一节讲了 CPU 使用率是什么,并通过一个案例教你使用 top、vmstat、pidstat 等工具,排查 CPU 使用率的进程,然后再使用 perf top 工具,定位应用内部函数的问题。不过就有人留言了,说似乎感觉 CPU 使用率...
  • L1-Day25

    2019-05-14 16:29:00
    的解析 5.14 日 星期二 一、【写出适当的介词】 1. 体会下列介词的侧重点 1、在黎明 ...【的翻译】at daybreak ...【对比分析】dawn与daybreak两个词可以互换. ...【的翻译】at 8pm 【标准答案】...
  • 本文产品猎人“Hunter”计划投稿作品不少PM都对同行人士“装逼”深有同感:他们动不动就搬上方法论,逻辑,同理心……更让人吐槽的是,一个二个没生过孩子的说产品就是自己孩子……把简单道...
  • 为什么使用Linux

    千次阅读 2016-12-29 22:45:16
    已经半年没有使用 Windows 的方式工作了。Linux 高效的完成了所有的工作。 GNU/Linux 不是每个人都想用的。如果你只需要处理一般的事务,打游戏,那么你;)%0 不需要了解下面这些了。7rm?zA ©达内科技论坛 – ...
  • 程序员对抗雾霾可以做些什么

    千次阅读 2015-12-02 11:35:55
    就像周末那篇文章里说的一样,雾霾大哥来了,这次礼物貌似以前贵重很多,到处散发着泥土的芬芳,让人吸的有点窒息,吃的有点噎的上,让人难以下咽。自从有雾霾这个概念以来,帝都的精神就变了,变成了:“厚德载...
  • 为什么软件开发的实际工作量通常估计的几倍? 我们来看一个故事就明白了:作者:Michael Wolfe翻译:童角大王我们决定沿着旧金山到洛杉矶的海岸线来一次远足旅行...
  • 今天期末考试过后突然闲下来,翻书翻着翻着突然想起了一个问题:为什么,Why we need the imaginary number? ,为什么我们需要用到虚数iii? 然后的数学物理大厦又双叒叕(yòu shuāng ruò zhuó)崩塌了 ...
  • 蓝色关注,回复“1”获取知名公司程序员和产品经理职级第「135」篇原创。产品经理程序员,职场问题找军哥。见字如面,是军哥。前几天读者群里有一位伙伴说,部门有几位同事技术不怎么样,但...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,576
精华内容 1,430
关键字:

为什么家里pm25比外面高