在IT企业中PD和PM职位差别是什么，具体都干些什么工作啊！

这篇文章主要总结了我对于敏捷项目中总体测试策略的理解，主要来自于工作上的实践和思考。

先看下维基百科上关于 test strategy 的定义

归纳上面的定义，我们可以得出测试策略的最终目的是通过定义项目会采用的测试活动，尽可能得暴露和消除产品缺陷，减轻产品风险。除此之外，由于软件开发时常伴有交付压力，测试的时间和资源都是无法保证甚至可能被压缩的，所以测试策略还会从最低成本揭露产品质量风险出发，选择出最合理的测试方法和测试过程。

基于上面的定义，可见测试策略解决了两个大问题：

在详细点就是：

要说不同，先看定义上的不同。

由上可见，其实测试策略的内容已经被包含在测试计划里面了。测试策略定义应该做什么样的测试而测试计划包含所有关于测试策略该如何执行的信息，这些信息在测试计划里面被很好的组织起来。

一个公式可以进一步说明他们的关系 test plan = test strategy + test logistics 。所以test strategy可以被看做是test plan的一部分。 Test logistics 是指测试环境设置以及人力资源等等。

在James Bach的博客 A Question About Test Strategy 中，他把三者描述如下

让我们先来看下QA在敏捷项目中的主要工作，如下图所示

那你可能问“咦，怎么没有测试策略相关内容呢”。其实，整个开发测试流程就体现了测试策略的内容。上图所示的迭代开发流程里面包含了"Automated Acceptance Tests" & “Story Testing” & “System Testing”这些测试活动，那么为什么项目需要这些测试活动？这些活动如何具体如何开展？分别在哪一个项目阶段进行？这些问题都属于测试策略的范畴，是由测试策略定义和落地的。

敏捷开发模型下，迭代式的开发具有周期短和交付压力大的特点，对于如何快速响应新需求，保障新需求的质量以及已实现需求的回归测试都将是测试的挑战。如果没有一个匹配项目上下文，合理规划了测试活动的测试策略，这些挑战就会持续困扰着团队，所以标题的答案是当然需要。测试策略在敏捷开发模型下，通过详细定义项目的测试活动，能够更加合理地利用测试资源和统一项目对测试的认知。

此外，测试策略也是敏捷项目质量保障体系中重要的一节。

在传统瀑布开发模式下，测试计划test plan被认为是项目测试流程的关键部分，因为它指导着整个测试活动的开展，既然被认为是项目中的一个must have，于是有人会花很多时间很多精力去把测试计划给写好写完整。那么我们真的在敏捷开发模式的项目里需要一份测试计划吗？这真的能给项目质量带来价值吗？

敏捷宣言说过：

在敏捷项目中，产品范围也就是发布内容在spring进行之前就被讨论，所以QA们对于测试对象和测试范围一直都是清楚的，不需要特别地花时间去写一个详细的文档来阐述。同样地，agile ceremony会让QA们清楚地知道测试对象是什么，范围是什么，重点是什么，测试环境是什么而不需要一个单独的文档来进行详细的描述。甚至，所有关于测试的信息还可以被记录被故事卡中。在开发进行编码实现功能的时候，QA们会进行测试用例设计以及自动化测试编写，因为时间的紧迫，QA除了这两项测试活动，再去写一个详细测试计划是不经济的且价值不大，这两项测试活动才是敏捷项目中价值最高的，况且随着迭代的进行，测试计划的维护还需要时间精力。

综上所述，在敏捷项目中因为时间紧迫和避免重复劳动，价值不高的测试计划不是一个must have，个人甚至认为也不是一个nice to have。但是这并不是代表我们不需要"planning"，而是不是需要"document planning"，"planning"的实施发生在迭代中的各类活动。

最终我们还是需要一个“计划”来指导迭代中的测试流程和方法，这就是测试策略是一个must have的原因。在敏捷项目中，“小而精”的测试策略比起“大而全”的测试计划而言，最大的优势就是测试策略定义的内容(“怎么测”)是不会轻易受影响改变的，并且在迭代中没有类似的重复活动。

具体到项目里，测试策略推荐在项目刚启动的时候制定。测试策略需要在项目早期就制定下来，用来指导项目的测试活动和方法，从而确定需要的测试资源和保证质量体系的建立。但也不能在产品和技术都还没有确定的时候就制定，因为只有在产品需求范围，技术架构和交付计划大致确认的情况，测试策略才能更加准确，从而减少维护成本。

因为测试策略会涉及到很多具体的测试技术和方法，也会要求制定人员具有对质量和测试非常深的理解，所以QA在敏捷团队中应该承担制定测试策略的主要责任，但是这并不意味“只有”QA来编写制定测试策略，测试策略的制定是一个团队活动，QA需要从不同角色收集到不同的信息

从多方收集信息能够保证业务、技术和质量三者对齐，避免误解和冲突，共同发挥最大的作用。

当测试策略制定完成以后，还需要给项目团队进行讲解，确保团队所有相关人员对项目中的测试活动和测试方法有着一致的理解,这样才能保证实施阶段的顺利。

接下来会涉及到QA制定测试策略的具体活动及流程。总的来说，大体流程可以如下

上面提到了QA可以从不同角色收集到不同的信息，除此之外，使用启发式测试计划语境模型 Heuristic Test Planning Context Model和启发式测试策略模型 Heuristic Test Strategy Model也是一个有效的渠道。具体如何使用这两个模型，请参考 htsm 和 htcpm 。

通过分析 htsm 中“项目环境”和“产品元素”的关键词和启发式问题，QA可以了解关于产品和项目的各类信息来帮助制定测试策略。 htcpm 也提供了大量的关键词来启发QA去分析了解产品需求、项目环境、测试小组和测试资源。

可以收集的信息大致可分类如下

只有从不同的维度收集到足够的项目信息并且很好的理解这些信息对项目质量和测试活动的影响，才能帮助我们少走弯路，制定出适合项目和团队的测试策略。

在具体思考“怎么测”之前，我们需要确定项目的质量目标。这个质量目标会对齐项目所有相关人员对于项目质量的理解和期望，明确质量范围也就是测试策略会覆盖的范围。同时，质量目标也要与产品目标对齐，因为质量的最终目的也是保证产品的成功。根据产品在不同阶段都有不一样的目标，质量目标有会随之变化。

那质量目标如何设定？主要是参考软件质量特征列表和软件质量模型，建立符合项目上下文的产品质量模型，从而确定项目质量目标

要建立项目产品的质量模型首先就需要先知道一个软件产品的质量属性或特征分别有什么，对应的质量模型是什么样的。幸运的是现在已经有很多可以参考的模型了

ISO/IEC_25010的质量模型大致如下：

从上面的质量特征列表或是模型可以看出，一个软件产品的质量由多个质量特征或标准组成，每个质量特征又可以进一步分解为子特征。通过这些已有的质量模型来启发哪些质量特征是对项目产品重要的，哪些质量标准适用于本项目产品，最后得出符合项目上下文的产品质量模型。

比如 我们创建的产品质量模型可以包含以下粗粒度特征：

上面的质量模型定义了产品质量特征和标准，而这些特征和标准就是我们应该完成的目标！除了上面说到的质量模型，一些具体的metrics也可以被引入来保证项目质量，成为项目质量目标的一部分。举个例子

上面提到的标准都是可以通过集成到持续集成流水线的质量工具或测试框架来实现。

此外，还有团队也会使用测试策略目标宣言来打造团队文化。

有了质量目标，接下来我们要考虑要怎么达成这个目标了！也就是说，我们应该有哪些测试类型来覆盖每一个质量目标？

测试类型按照不同维度可以有很多种分类，比如说

当然，上面只是列出了一部分。

此外，HTSM中的 Test Techniques 提供了九种通用的九种测试技术来启发对可应用的测试类型的思考。敏捷测试四象限也提供了敏捷项目可以参考的测试类型,这个测试技术分类系统可以帮助我们快速定位某测试类型在软件开发中的位置，根据项目产品情况选择合适的测试类型。

就以我们上面假设的质量目标为例，我们来看看可以应用哪些测试类型

值得注意的是，并不是每一个项目都需要覆盖上面所列出的测试类型。我们应该根据产品的目标和特点以及其他实际情况选择与之对应的测试覆盖类型，也就是说，不同项目根据测试类型的不同，测试广度是不一样的。同事，根据测试的难点和重点，测试深度也是不同的。所以，一切都要基于项目的上下文来思考和制定。

自动化测试金字塔用来指导敏捷项目中自动化测试的策略。

根据金字塔理论，项目应该在底层的单元测试和集成测试(API测试)投入更多的精力。

自动化测试项目会被集成在持续集成流水线里面，由上游项目自动触发。为了减少持续集成的反馈时间，一个普遍的做法是把庞大的自动化测试套件集依据重要性优先级放在不同的流水线里面，可以被上游项目触发也可以定时触发，下面描述了一个比较好的实践：

确定测试类型之后，我们就知道了整个项目的测试活动会有哪些。对于某些测试类型，特别是自动化相关的测试，我们需要对应的测试工具或是框架来支撑我们的测试。所以我们需要对每一个测试类型都去思考下如何进行测试，是否需要相应的测试工具和框架的支持。

拿一个web程序来举例

这个环节我们需要确定在项目开发生命周期的每个阶段做什么样的测试，使得测试类型与项目的开发流程充分结合，这样就能最大发挥所有测试活动的效果来达到我们的质量目标。因此，我们可以做出类似下面这样的表格来表现每个阶段的测试类型及其实施方法。

至此，测试策略解决的两个问题“测什么”和“怎么测”都可以找到大致答案了。

那如何衡量测试策略的有效性呢？质量度量可以告诉我们产品的质量情况和用户满意度，从而反应出测试策略是否有效和高效。

软件质量的度量没有什么最佳实践，也没有最准确和科学的度量，有的只是项目上积累的成功经验；但是这些成功经验又由于项目差异化太大而变得复用性很差。所以根据项目的上下文，我们需要制定出自己的质量度量标准。结合本文敏捷项目的背景，我们可以大致使用下面常用的度量：

同时，实例化的质量目标也是很好的项目质量的工具。对于质量模型，我们可以看下每一个质量元素我们是否做到；对于具体的指标metrics，要随时监控反馈。

一旦测试策略被确定，一般来讲不会经常变化，因为测试策略设置了一些测试标准。如果测试标准频繁地变动，这会让具体计划的执行变得困难，同时带来更多的资源浪费，最终影响了项目的质量。

在项目中我们会经常遇到“变化”：比如说

这些变化对测试的影响是被测对象的范围以及项目资源的调配。对于项目的质量目标、测试类型、测试阶段影响不大。所以，测试策略一旦被制定出来，变化不会太大。

不过这不代表测试策略的一成不变和缺乏改进，QA需要在每个迭代中观察测试策略实施的效果来决定当前的测试类型和实施手段是否满足项目需求。比如当项目集成测试(API Testing)经常fail，且协调工作耗时费力，QA可以考虑采用契约测试来代替现有的集成测试，提高整个项目组的生产率和质量；比如发现Internet Edge突然用户量增多且有关于Internet Edge的production bug被raise，QA需要把Internet Edge加到兼容性测试中，并且设置相关的测试环境；比如测试进度落后，交付压力增大，QA需要及时调整测试范围和测试重点，进行风险分析。

在实际项目中，往往会出现各种各样的问题来阻碍测试策略的顺利落地和执行。这些问题有些是测试策略自身的问题，但也有项目带来的问题。这时候，风险分析显得格外重要。

对于测试策略的风险分析，这个是应该贯穿整个测试策略制定周期里面的，我们需要通过项目风险清单提前识别项目中可能阻塞测试的风险，并通过风险优先级(风险暴露的概率风险暴露的损失)来评估风险，最终基于风险调整测试策略，把测试重点放到风险高优先级高的地方。

测试策略是影响质量的重要因素，但不是全部，下面列出了部分会影响质量的因素作为参考，在此文中不会展开来讲

上面详细阐述了我如何理解敏捷项目中的测试策略以及制定测试策略的具体步骤。由于IT项目的多样性和复杂性，这个总结不可能适用于有着不同上下文的项目，因地制宜地制定测试策略才能保证测试策略在项目中的可用性和合理性。

在敏捷团队里，经常听见很多不同的声音：

有人说，“好的敏捷项目管理者就要做打杂的，什么都不用干，什么杂事她都能干”；

有人说，“敏捷项目管理者经常受到挑战，因为他们没有一技之长”；

有人说，“敏捷项目管理者权威感太弱了，很难把事情推行下去”；

有人说，“要不然没想法，要不然搞不定事，管理的角色可有可无”；

总之，一千个人有一千种对于敏捷项目管理者的画像。

连敏捷项目管理者自己也经常发出这样的悲鸣，“敏捷项目追求扁平，项目管理者事杂权少 *** 心多，关键时刻还要站出来背锅，真的毫无存在感，这个角色的意义何在？”

或许只有见识过优秀的项目管理者，他们没有“管理者的权”，却 *** 着“管理者的心”，但仍然表现优秀的管理着项目，无论是普罗众生，还是项目管理者本人，才会认识到什么是优秀的项目管理者，还有什么是可以从优秀的敏捷项目管理者身上学习的。

我见过许多优秀的敏捷项目管理者：

他们具备“常识感”，哪怕项目规模再大，但心里一直住着一个既普通又全能的角色，他们能准确判断风险，然后快速抓到问题的本质，通过整合身边的资源，做到合理合适的匹配和应对；

他们一心关注在问题的解决上，似乎从不关注存在感，也无暇关注存在感，毕竟，为不同的事所困是项目的常态，他们不在应战，就在为应战做规划和准备；

当他们看到有人做的更好，会认识到他自己还有团队的成长取决于学习的速度，所以会带着团队一边向别人借鉴，一边快速累积自己的经验。

在我看来，这些项目管理者之所以优秀是因为具备两种力量，一种是决策力，一种是影响力，在这两种力量的支撑下，他们能够在能力、心态和认知上有突出的表现。

决策力指的是基于形势做出正确的判断，然后快速行动，影响力指的是影响团队和干系人，在目标上明确，在行动上一致。

按照两种能力程度的不同，可以把项目管理者的状态分为四类。

也就是文章开头里描（TO）述（CAO）的那种，在敏捷团队里，大家为共同的目标承诺和担责，共同维护一个开放尊重的环境，平等沟通，协商共事，没有职权没有命令，所有人被鼓励勇敢的说出想法，既包括互相提反馈，也包括集体做决策，每个角色有一技之长，既有分工又形成合作，一起完成目标。

项目管理的工作被多人分担了，那项目管理者（PM）是不是很多余？管理者的存在感何在？

此时，很多项目管理者会给自己加戏，帮助BA（需求分析师）写写故事卡（story），帮助 UX（设计师） 出几个图表，帮助QA（质量保证师）执行几个测试用例，戏多了自己就会忙碌起来，甚至有的项目经理会为自己贡献的这种价值感动，“看我的设计能力是不是不错？”，“我今天写了10个story。”

项目经理偶尔的承担上述事情是团队发挥协作精神的体现，出发点和责任感都是没有问题的，但一个优秀的项目管理者更清楚自己的责任和使命，他们如果没有把时间放在解决当下的问题上，便会把时间和精力用来做长远的判断和规划。

这些都是他们思考的问题，也都是他们持续规划、日常推进的事情。

“人无远虑必有近忧”，优秀的项目管理者深知这个道理。不想天天扑火，就需要做长远规划。

所以，当管理者抱怨没有存在感的时候，先问问自己，你因什么而存在，你有什么是不能代替的，你都做了什么，你和大家的差异点在哪里？

此处要划的重点是，既然承担了项目管理的角色，就要像个管理者一样去思考，去观察，去想解决方案，而不是努力把自己培养成BA，QA或者其他“存在感强”的角色，如果没有做到，那想想如何做，怎么做，最为关键的是想清楚为何这么做。

这是一种很悲催的状态，事实上，可能并不是因为项目管理者缺少能力，也不是态度不好或者责任感不强，相反，还很可能是有态度，有责任，想做事，也一直在做事情，所以和团队产生了距离，甚至是矛盾。

比如，和客户拉通了目标，但是没有及时和团队更新，以至于团队在错误的方向上做出了很多不必要的努力；

比如，把个人的决策当成了团队的决策，在客户和团队之间制造了许多无效沟通和反复确认；

比如，从管理的角度制定了规则和流程，但并没有从执行层面做充分论证，以至于难以推行；

比如，细节管理，事事过问，团队的日常充满各种沟通和更新，团队成员不堪其扰，团队管理缺少灵活和创新；

看似管理者很有存在感，一直冲在前面做客户沟通、做决策、做计划，事无巨细，事必躬亲，但管理者的工作却经常受到挑战，不是来自团队，就是来自客户，渐渐沦为孤家寡人。

一个优秀的敏捷项目管理者深知，如果团队别扭着，是无法和客户建立信任的关系并给客户带来真正的价值的，所以她会把敏捷的文化和敏捷的实践活动当做有利的工具，帮助自己把决策执行下去。

最典型的场景莫过于面对意料之外的变化和风险，尽管管理者已经积攒了数百条最佳实践，但仍然能够从透明、公开、平等的原则出发，客观分析，细心引导，让自己的经验“变成”大家群策群力的结果，因为参与过思考的过程，所以每个人都会觉得自己有贡献，因此在执行的时候，那种凝聚力，以及对于目标的认同程度，是相当坚决的。

此处要划的重点是，作为管理者，如果只是觉得自己有好的想法是远远不够的，比这更重要的是让更多的人理解自己的想法，并基于此产出更多更优秀的想法。

这便是影响力，它不是来自于职权，也不需要靠什么手段，它是一种引导的技巧和沟通的能力，它能让自己的想法和思考变成大家的想法和思考，用一个人的智慧点燃整个团队的智慧。

有的管理者是大家公认的好人，在某种程度上甚至还是“名人”，他们善于处理人际关系，烘托团队气氛，所以在这种团队里面更多的是看到和气，而非争议。

但是这种项目不一定成功，个人也不一定能获得成长。

管理者像个外交家，花大量的时间来构建和维持各种关系，有效的，没效的，与此同时，管理者擅长把收集来的各种信息散发给团队，今天有今天的方向，明天有明天的重点。

这样做看似是一种非常透明的管理方式，因为信息传递的渠道是畅通的，管理者能分发自己获得的全部信息，也能及时获得团队的信息，但这些及时又碎片的信息虽然能指导行动，但在目标上不一定统一，因为在这过量又繁杂的信息背后，缺少提炼，缺少体系，缺少和目标的联系。

所以，团队有可能做了很多事情，但并不一定是服务于目标的努力，也因此，很多时候团队会忙于处理各种偏差带来的问题，不停的打着各种补丁，项目推进的过程险象环生，如履薄冰。

优秀的项目管理者理解信息是碎片的，多变的，所以会对信息进行解读，提炼出重点，基于获得的信息，项目的现状，要实现的结果进行系统思考，做出正确的判断，然后带着团队一起强化目标，或者修正方向。

此处要划的重点是，管理者不能只做传声筒，很多时候要做专业的过滤器，用管理的思维来过滤碎片的无效的信息，既是保护了团队免受杂音的干扰，也是在发挥自己管理的特质和优势。

如此，在方向和执行上，管理者便是那个团队可倚重和信赖的人。

这也就是传说中的优秀的敏捷项目管理者了，这可能是最令人羡慕的一种状态了，但并不代表管理者就此可以躺平。

处在此状态下，管理者既具备决策力也具备影响力，但并不代表项目上不会出现问题，只是当问题发生了，管理者总有思路去应对。

优秀的项目管理者会关注三件事情，一是遇到问题时寻找共性，从自己和项目的过往中寻找经验，识别出共性，快速形成判断力和决策，然后带着团队一层层分析，一点点拆解，把不理解的问题和看不透的逻辑变成可以用大家的认知来理解的事情，进而利用团队的力量去解决问题；

二是能够认识到团队的优秀依赖于个体的优秀，所以会用细心和耐心带着团队一起分析和解决问题，有的时候扮演导师，给予他人鼓励，有的时候扮演教练，给予动作指导，有的时候又是老师，传授新的知识和能力，此时的管理者，更愿意自己搭台子，扮演幕后的角色，给队员制造机会去表演去历练，此种做法，个体获得成长，团队获得战斗力。

三是认识到，一个项目不仅仅是实现价值，也是一个学习的组织，这个组织能够快速成长取决于学习知识的速度，这个组织是否有未来，取决于它累积知识和经验的能力，因此，一个优秀的项目管理者会把每个项目当成学习和沉淀的机会，在管理项目的过程中完成经验的积累、人员的发展和知识的传承。

所以，一个优秀的项目管理者会同时关注过去，现在和未来，他们不打无准备之仗，他们每打一次仗也都没有白打。

如果你遇到一位优秀的项目管理者，好好珍惜和他共事的机会，因为和成熟的管理者共事，受益最大的是项目和项目里面每个渴望成长的你。

当你还在为自己是一个无权无存在感的敏捷项目管理者而悲叹时，你可能还需要跨越一些障碍，但最大的山可能不在眼前，而在心里。

PM：产品经理。

一个产品，是由PM来分析细分市场、目标客户的诉求，规划产品的卖点。

PM是产品经理（Product Manager），企业中专门负责产品管理的职位，产品经理负责市场调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等。

PD：直译为产品设计师，也可能叫产品规划师、需求分析师。

PD侧重于应用功能级的设计，技术团队中的架构师（或者系统分析师，也可能叫项目经理、开发组长）

PD在IT企业中，一般是Product Director（产品主管）或Project Director（项目主管）的意思，比Project Manager（项目经理）级别要高。

：

IT的英文是Information Technology，即信息科技和产业的意思。

它主要是应用计算机科学和通信技术来设计、开发、安装和实施信息系统及应用软件。它也常被称为信息和通信技术（Information and Communications Technology，ICT）。

主要包括传感技术、计算机与智能技术、通信技术和控制技术。

IT业划分为IT生产业和IT使用业。IT生产业包括计算机硬件业、通信设备业、软件、计算机及通信服务业。至于IT用业几乎涉及所有的行业，其中服务业使用IT的比例更大。

IT行业不仅仅指通信业，还包括硬件和软件业，不仅仅包括制造业，还包括相关的服务业，因此通信制造业只是IT业的组成部分，而不是IT业的全部。

种类

信息技术产业主要包括三个产业部门：

①信息处理和服务产业，该行业的特点是利用现代的电子计算机系统收集、加工、整理、储存信息，为各行业提供各种各样的信息服务，如计算机中心、信息中心和咨询公司等。

②信息处理设备行业，该行业特点是从事电子计算机的研究和生产（包括相关机器的硬件制造）计算机的软件开发等活动，计算机制造公司，软件开发公司等可算作这一行业。

③信息传递中介行业，该行业的特点是运用现代化的信息传递中介，将信息及时、准确、完整地传到目的地点。因此，印刷业、出版业、新闻广播业、通讯邮电业、广告业都可归入其中。

信息产业又可分为一次信息产业和二次信息产业，前者包括：传统的传递信息情报的商品与服务手段，后者指为政府、企业及个人等内部消费者提供的服务。

参考资料：

IT行业——百度百科

1、Dev：软件研发技术负责人

软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。

2、RD：研发（Research and Development）

如：软件RD工程师就是软件研发工程师，诸如PHP程序猿，Java程序猿，无论是爱疯的还是安卓的都是属于这一类别。偏向于后端的技术实现。

3、CPO：首席产品官（Chief Product Officer）

首席产品官把首席技术官（CTO）和首席市场官（CMO）这两个角色合二为一，注重用户体验，从而为公司赢得市场发挥重要作用。

4、TeamLeader： 项目组长

项目组长主要与团队成员一并商讨，问题的原因，最终达成共识，确定解决方案。

5、QA：测试（QUALITY ASSURANCE，中文意思是“质量保证”）

为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能，担任这类工作的人员就叫做QA人员。

6、PM：项目经理( Project Manager )

从职业角度，是指企业建立以项目经理责任制为核心，对项目实行质量、安全、进度、成本管理的责任保证体系和全面提高项目管理水平设立的重要管理岗位。项目经理是为项目的成功策划和执行负总责的人。

7、PO：产品运营(Product Operation)

在互联网行业，尤其是阿里巴巴集团，PO是产品运营的缩写，全称是product operation，隶属于产品部门，与PD（product design ，产品设计）相对应。

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:product manager（产品经理）负责根据市场负责公司产品的选型，更新，等一系列工作。很累，很烦。有些公司的PM是有业绩压力的 CSDN上面这方面东西多的去了

ACP敏捷项目管理有别于传统的基于PMBOK或PRINCE2的项目管理模式，敏捷项目强调商业价值的尽早交付，项目团队的自组织，不断响应客户动态的需求变化，持续的优化项目产品和交付流程。

选择师资有保障的网课公司可以事半功倍，选择PMP培训机构和项目管理相关课程，需要对比的无非是机构的资质、师资、服务这三个方面，官方资质，师资强大，服务良好自然就指得推荐，比较推荐艾威培训，首先是资质，报考PMP的资格要求中，有一项硬性要求是需要提供35学时以上的涵盖PMBOK中10大知识领域的完整培训经历的项目管理培训证明，该证明只能由PMI授权REP注册教育机构提供，否则无法进参加PMP考试，而艾威培训是美国PMI 2003年授权PMP培训机构(PMI REP1887)，直接与PMI合作，培训有保障。

从历史上看，无论谁是项目的技术负责人，也需要做项目管理的工作。尽管我们的系统和流程变得更加相互依存，然而，我们却开始看不到未知的依赖关系和涟漪效应。当我决定使我的IT团队能够胜任项目管理时，我想这将是非常简单的：培训或聘请一些好的项目经理，并让他们做这些工作。但当我开始思考在我的IT组织中真正需要的角色时，发现建立项目管理能力并不是那么简单。正如我在我的项目管理需求中反映的，我确定了三个对我的成功非常关键的非传统项目管理的特点：·敏捷或迭代法必须是项目管理的基础。·项目管理必须积极主动地管理并化解风险。·项目和项目状态必须是可见的。项目管理的敏捷或迭代方法正如我前面所述，敏捷方法帮助解决了传统IT项目问题的范围。我们应该将每一个IT项目分解成更小、更易于管理的块。这样在每一块的结束，我们可以适应变化。然而，这项建议不应意味着我们可以自有改变一切。有效的敏捷项目管理的规则之一是，在当前的块中，我们确定将做什么，然后让团队交付该块。如果有人改变了主意，当我们计划下一块时，我们应该考虑这些变化。敏捷项目管理必须主动减轻风险若干年前，我开始思考以一种更加自觉地、积极主动地方式管理风险。传统上，项目管理使用紧张的控制过程缓解风险。然而，那些过程和敏捷这种要适应变化的方法共同存在是有困难的。我的用于积极主动的风险管理的方法在最初的项目规划期间就开始了。我创建了一个项目风险概况，将项目风险划分为三类：交付风险（时间、预算和目标上的风险）；业务案例风险（不正确的假设的风险）；和附带损失风险（当该项目交付承诺的、但在别的方面有可怕的涟漪效应时）。一旦我们在这三个类别中识别到风险，我们就会确定其来源。它们是因为不确定性？（例如，有商业案例的风险，由于预期收益是没根据的猜测。）或者是因为复杂性吗？（例如，交付风险，因为我们使用的是一项极其复杂的集成技术。）随着风险类别和来源被确定，接下来我们确定具体的项目任务，它们将遇到和减轻风险。在一般情况下，如果风险的来源是不确定的，我们使用敏捷或迭代的方法来降低这些风险。例如，我们会做一个小规模的试点来确定尚未明朗的好处。然而，如果风险的来源是复杂的，我们分离并简化我们所能做的。在每个项目块或迭代周期结束时，我们更新风险状况和缓解步骤--再像其他事情上以上，预期风险将会发生变化。项目和项目状态必须是可见的持续过程改进的格言之一是，我们应该能够通过简单的查看，说出每一件事情的状态。同样的格言适用于项目管理能力。我们现在生活在一个每个人都想获得一切的环境中！那么，为什么我会让我的项目利益相关者等待我去收集、记录和分发有关他们的项目信息？相反，我应该有一个项目状态可见的方式--这意味着，利益相关者可以通过简单的查看告知项目的状态--几乎实时。这怎么可能呢？首先，我要保持我的项目状态需求在最低限度。否则，状态报告可以是繁重的--繁重的任务具有不能实时完成的倾向。其次，我应当使项目状态信息可访问。我们使用可视化的显示（在我们中间的那些"敏捷开发者"应当考虑典型的信息传播源），以及简单的、项目团队可以更新且利益相关者可以访问的技术仪表板--再没有太多的麻烦。项目管理在我们的成功中起着至关重要的作用，但它必须适应我们的组织对我们的要求。在我的生活中，我既没有时间也没有空间用于官僚的项目管理过程。当我做迭代项目时，我得到我需要的。迭代项目主动管理风险，对任何人以及所有利害关系方可见。

以上就是关于敏捷团队中的测试策略全部的内容，包括:敏捷团队中的测试策略、如何成为一名更优秀的敏捷项目管理者、在IT企业中PD和PM职位差别是什么，具体都干些什么工作啊！等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！