第一篇：it产品经理的工作职责
IT业产品经理必备的七项素质
貌似现在一个很常见的IT业新职位就是产品经理，很多大牛都自称产品经理，不过它确实是一个对个人综合素质要求非常高的职位，人称“产品灵魂的设计师”。有志于成为优秀产品经理的朋友来看看下列哪些方面的能力可以帮助你更好地朝自己理想中的状态迈进。
一、沟通能力
成功的产品经理必须是优秀的沟通者。
从我所认识的优秀产品经理们分析来看，他们所具有的最共同特征是“在工作中具有优秀的口头及书面沟通技巧”。
为什么沟通很重要?在许多公司，产品经理最为一个决定性角色扮演着沟通枢纽的角色，如下图所示。
而在不同角色间有效沟通能力，往细了说，就是与不同的个性类型沟通的能力，即在用不同角色沟通的时候讲不同的“语言”。对于有效沟通来说，重要的是你使用目标听众的“语言”。
例如，大多数工程师倾向于是“内向型”，而大多数销售/市场专员倾向于“外向型”。这意味着，与工程师沟通相较而言，和市场专员沟通时需要使用“另一种语言”。同样地，当你和主管沟通时，相对于“树的级别”而言，你必须把更多的表述重点放在更高层次的“森林级别”，然而许多产品经理却错误的依然跟主管们在谈论着这颗树是多么的美丽。
二、没有权力的领导
成功的产品经理拥有在没有正式的权力下也能成为优秀的领导的能力。
多数公司，产品经理被期望在多个领域扮演“领导角色”。这包括领导项目团队，领导产品策划和路线图，领导跨部门沟通等。
然而，在多数这样的情况下产品经理并没有统筹这些部门的权利。
没有权力如何领导别人?我想说，使用联合影响，谈判，关系网和其他类似技巧。
没有权力是否可能领导?我对此的想法被这个问题总结的很好，我的回答是个反问：甘地和马丁·路得金有多少权力?
三、学习技巧
这点，用我个人的话来说，就是优秀的产品经理擅长做不擅长的事。
优秀的产品经理必须具备快速学习的能力，市场变化很快，新技术总是拔地而起。“差异化产品”在今天不到6个月内产生，有时甚至更快。
我认为多数公司在雇佣产品经理时会犯的一个错误是-他们看重“强悍的专业知识”。
举个例子，一个做软件安全的公司，他们寻找一位拥有5年以上软件安全方面工作经验的产品经理。我认为这是一个错误的方法。相反，51230.com的邵光荣老大哥就说过，他们产品部门招人，反而都是新手优先，因为怕过多的经验会限制创新能力和个性发挥，这也难怪，人家做的就是充满个性的婚恋网站。
当然，更好的方法是，寻找一个拥有适当工作经验的产品经理，并且拥有快速学习的能力。这种方法对我来说实现的很好，我手下那些最好的产品经理在被雇佣以前，都没有他现在所从事工作的专业知识。
四、商业敏锐度
成功的产品经理对基本的商业原则也有很好的理解。
他们了解如何辨认市场机会，竞争分化的重要性，创造成功产品的策略，定价，促进，合作，分析，声明，及其他。
这并不意味着他们需要工商管理硕士学位。实际上，我接触过的多数成功的产品经理并没有工商管理硕士，但是他们对商业基本原则都有着充分的了解。
五、热爱产品
成功的产品经理对产品有一种固有的爱。
他们因跟上市场上新产品的步伐而高兴，和他们的到手的一样多。他们注册了大量的“betas”网站，下载最新版本的软件并使用，等等。
他们为设计好的产品而高兴，即便并不是他们公司制造的。他们讨厌设计糟糕的产品，即便是自己公司制造的。
他们热爱创造伟大的产品，无论它是一个全新的产品，还是改进现有产品。
六、关注细节
任何事务是由细节组成的，关注细节,是创造伟大产品的必要基础。
SteveJobs曾经说过：
iMac不仅仅是颜色或是半透明或是外壳的形状。iMac的本质是使每一个元素集中在一起成为最出色的消费电脑。在我们最新的iMac，我坚定我们摆脱了风扇，因为使用一个不会一直嗡嗡作响的电脑工作让人更愉悦。
扔掉风扇不仅是Steve一个固执的决定那么简单，他背后需要一个巨大的工程，计算出如何更好的处理电源功耗，以及如何更好的通过机器散热。这是我们产品出发的核心点，顾客购买我们，就是为了让我们去解决所有这些细节，所以他们容易和喜欢使用我们的电脑。
成功的产品经理观注细节不仅仅是提到产品性能，并且在竞争力分析，项目计划，和几乎每个他们主要负责的活动。
我的话：同样，这种细节体现在你所做的报告中、计划中、任务策划书中。在内容上，请尽可能的描述到实施细节;在表现上，请尽可能的体现一个产品设计师的UI设计细节。如果一个连报告都不能让人愉快阅读的产品经理，怎么指望做出来的产品能有优秀的用户体验。
七、常规的产品管理技能
一个产品经理需要这些技巧来完成日常任务。他们包括写市场分析报告和需求分析报告，执行竞品分析，创造产品路线，陈述产品性能和利益，定义用户界面，等等。
每个公司都需要这样的技能。这一技能放在最后，是因为我认为拥有上述六点的产品经理很容易学到这些技能。
总结
也许这七项素质还不够，那就通过学习能力去学习更多吧，无论是专业素养还是个人成长，学习和提升从来都是无止境的。
第二篇：IT产品销售人员的沟通技巧
作为优秀的销售人员，仅仅能够识别、辨认人们的沟通风格还远远不够;要提高沟通效率，提升销售业绩，还必须学会沟通中的一些沟通技巧。尽管不同的销售人员，对于不同的沟通技巧敏感性不同，但是，掌握一些具有共性的沟通技巧依然十分重要。独具一格的富有个人魅力的沟通风格往往离不开娴熟的沟通技巧的锦上添花，从而促成销售沟通成为一种愉快、轻松与活泼的交流体验。
个性化的沟通技巧包含语言和非语言方面的沟通技巧。语言方面的沟通技巧包含倾听、应答、积极交流等;非语言方面的沟通技巧则内容比较丰富，包含副语言、表情、目光、体姿、服饰与发型等。
虽然在销售沟通过程中，语言沟通常常占到了主导的地位，但是脱离了非语言的配合，仅仅依靠语言媒介的信息传播，难免会使人感到词不达意或言过其实，僵硬呆板，缺乏一种幽默、生动或真情流露的情境。不过，非语言行为也很难独立担当起信息传递与人际沟通的功能，它们往往起着辅助、配合和强化语言的作用。因此，有效的销售沟通总是语言沟通与非语言沟通的合二为
一、天衣无缝的一种自然融合。 语言沟通
语言沟通是人们借助于口头语言或书面文字所进行的一种信息交流，它起到一种方向性和规定性的作用。口头语言沟通包括交谈、报告、演讲、谈判、电话联络等形式;书面文字沟通包括通知、报告、文件、备忘录、会谈纪要、协议等形式。前者沟通形式灵活、生动，反馈迅速;后者沟通形式正式、规范，具有严肃性、权威性，能够保证信息交流的准确性和保存的长期性等优势。现实中的销售沟通，往往是前期口头沟通居多(讨论客户需要、需求，谈判双方交易条件等)，后期是书面沟通居多(将前期讨论、谈判确定下来的需要、需求以及交易条件等以书面文字的形式描述出来存档，以备需要时查验等。
1.倾听与应答
优秀的销售人员一定是一个出色的倾听者。当客户提出问题时，他一定是去倾听而不是去指导，去理解而不是去影响，去顺应而不是去控制。不过，事实上大部分的销售人员都不是优秀的销售人员，因为他们不是出色的倾听者，造成这种现象的原因就是心理定势，即认为倾听是被动的。他们认为要想销售成功，就是要想方设法说服客户，因此，他们认为与客户沟通就必须努力说、努力讲、努力去证明或证实。实践表明，要在销售沟通中与客户建立良好的合作关系，销售人员首要的是应该学会倾听，倾听客户的需要，倾听客户的深层需求;同时向客户传递这样一种信息：我并不总是赞同你的观点，但是尊重你表达自己观点的权力。这就是人员销售中的“先迎合、再引导”原则。
欲成为一个优秀的销售人员，就应该经常主动地与客户进行交流沟通，在集中精力倾听客户需要、需求的情况下作出积极的反馈与应答。对客户的反馈与应答包括表现出注意听讲的身体语言，发出一些表示注意听讲的声音或顺应地提出问题等诸多细节。不过，在作出反馈或应答时，应避免人为产生的一些偏差，比如夸大或低估、过滤或添加、抢先或滞后、分析或重复等。
2.积极交流
掌握并善于使用积极交流的技巧，对于销售人员来说具有莫大的助益。首先，成功地促使他人改变态度和行为的原则是既要解决问题，又要不伤害双方的关系或对方的自尊。因此，措辞是否恰当是非常关键的，而采用恰当的措辞是积极交流的前提。其次，在积极交流的过程中，要善于使用“换挡”的技巧，即销售人员和客户(发送者和接收者)的角色互换，积极鼓励对方将想说的说出来，当客户表述的时候，销售人员
要仔细倾听;当客户准备倾听时，销售人员又要尽快转而阐述自己的思想、观点和情感。“换挡”技巧对于销售人员的好处在于使客户愿意听你讲;从客户的“诉说”中了解与掌握其不满意和反驳的理由;给客户提供一个畅所欲言的场所等。最后，积极的交流还要求销售人员在销售前主动与客户接触，在销售后主动与客户保持联络。
非语言沟通
非语言沟通是借助于人们的语音、语调、表情、目光、体姿等肢体语言所进行的信息交流。尽管语言沟通起到的是一个方向性和规定性的作用，但是，事实上非语言沟通才准确地表达了传递信息的真正内涵。概括地说，非语言行为在信息沟通中不但起到了支持、修饰或否定语言行为的作用，而且在某些情况下，还可以直接替代语言行为，甚至反映出语言行为难以表达的思想情感。
1.副语言
副语言是指说话的语音、语调、语气等，比如语音低沉、稳健或激昂、高亢等，语调的高低，语气的轻重，节奏的快慢等，它们伴随着语言表达信息的真正含义，因而副语言与语言之间的关系非常密切。研究发现，副语言尤其能表现出一个人的情绪状况和态度，影响到人们对信息的理解以及交流双方的相互评价。
2.表情
表情是人类在进化过程中不断丰富和发展起来的一种辅助交流手段。表情不仅能够传递个人的情绪状态，而且还能够反映出一个人的喜、怒、哀、乐等内心活动。
3.目光
目光是非语言沟通的一个重要通道，“眉目传情”就是一种很好的说明。事实上，在人际交流沟通中，有关沟通双方的许多信息，都是通过眼睛去收集和接收的。目光，作为一种非语言信号，销售人员使用目光可以向沟通对象传递肯定、否定的态度，质疑或认同等情感信息。在人员销售的沟通中，销售人员要善于使用目光，如用目光来表示赞赏或强化客户的语言或行为，用目光来表示困惑等。
4.体姿
所谓体姿，就是指人们在交流沟通过程中所表现出来的身体姿势。比如前倾、后仰、托腮沉思等状态或姿势。研究表明，无论多么老练、深沉的沟通，人们对待他人的态度都很难在体姿上给予掩盖或隐藏。虽然体姿不能完全表达个人的特定情绪，但它能反映一个人的紧张或放松程度。因此，销售人员若能准确识别并判断不同体姿透露出来的不同信息，对于促成销售，提升销售业绩具有极大的帮助。
5.服饰与发型
个人仪表，尤其是销售人员的服饰和发型是其沟通风格的延伸与个性的展示。有研究显示，服饰的重要性，甚至成了销售人员通向成功之路的决定性因素之一。人们普遍认为，着装正式不仅是职业化的表现，更是对客户的尊重。此外，销售人员还需要关注自己的发型，来自对客户的抽样调查认为，销售人员的发型不宜过于个性化与时髦、前卫，否则会给客户留下一个过于超前而显得不太稳重的印象。因此，销售人员通过其服饰与发型等外表所传递的非语言信息应该是积极、进取、热情、开朗、沉稳、健康的，这样才容易获得客户的认同。
6.肢体语言
对消费行为的深入研究发现，销售沟通过程中，客户一般会通过三种肢体语言来传递非语言信息，表明对销售人员的传递的信息持反对、犹豫还是接受的态度。这三种肢体语言就是面部表情、身体角度和动作姿势。表1列举了客户持不同态度下的三种肢体语言的表现形式。销售人员熟知这些肢体语言，对于把握客户购买心理，审时度势作出销售决策至关重要。
需要强调的是，虽然大多数肢体语言的含义明显且明确。但销售人员务必需要分清楚的是客户的肢体语言是其沟通过程中的一个组成部分，且是伴随着客户一连串的语言沟通中的一部分非语言暗示，销售人员切勿断章取义，但也不能熟视无睹。销售人员需要随时捕捉这些微小的非语言信号，并结合整个沟通过程进行正确地“翻译”或“解码”。
沟通中的障碍与润滑剂
1.沟通中的障碍
有效的沟通技巧，需要巧妙地避免沟通中出现的这样或那样的沟通障碍。所谓沟通中的障碍，就是指信息在沟通过程中遭遇诸如环境噪音等因素所导致的信息失真(放大、缩小、偏离)或停止(中断)等现象。引发信息沟通障碍的不仅有信息发送者的因素，也有信息接收者的因素，此外更可能是传播介质(传播通道或载体)方面的原因。表
2、表3分别列举了信息发送者和信息接收者常见的沟通障碍及其表现。销售人员熟知这些沟通中的信息障碍并努力避免这些障碍有助于提高沟通效率。
2.沟通中的润滑剂
积极的沟通不仅是有效销售的前提，而且也是销售人员将公司的理念与价值观、产品与服务、公司品牌与形象等向客户传递、传播和扩散的过程。积极沟通少不了沟通中的润滑剂。沟通中的润滑剂不仅能够帮助调节沟通氛围，在某种程度上，它还可以促进沟通双方对沟通问题的理解与认识。表4列举了销售过程中常常用到的沟通润滑剂。销售人员掌握这些润滑剂对于提高自身的沟通技能大有裨益。
第三篇：产品经理的主要职责
在《启示录》中，主要对产品经理的主要职责进行了二项分类：
1、评估产品机会
产品的需求来源很多，可能是高层的意见，可能是市场用户的反馈，可能是产品团队的点子，也有可能是专业人士的分析，而这些点子总是会掺杂部分伪需求和不占大多数的个体需求，需要有人来进行统一的审核和取舍，也就是常说的对产品做减法。 在初期只专注于产品的核心需求，产品经理就是负责这项工作的人，这项工作也是产品经理工作的重中之重，这项工作是在产品的概念化阶段完成的,交付产物为《商业需求文档(BRD)》、《市场需求文档(MRD)》。
2、定义要开发的产品
当评估产品机会结束以后，如果得出的结论是产品依旧可以开发，那么就要有人来将这个概念化阶段的需求功能点，转换成UI设计师、开发人员、高层能看懂的产品模型。
主要工作是制作产品的线框图(axure即可完成)和主要复杂功能的流程图(例如：支付流程图-visio即可完成)，在完成原型之后，邀请目标用户，对原型进行可用性测试，验证自己的想法能得到用户的积极反馈。
在这一阶段，产品团队的交付产物应该是《产品需求文档(PRD)》(不一定是word格式，现在提倡的在axure中进行批注是一个不错的方法)，这一阶段完成之后，产品就进入了开发阶段，产品团队要做的保证开发的顺利进行和开发出正确的产品。
《启示录》这本书中对产品经理的主要职责，进行了以上两大类，并没有将产品经理的其他细化职责归并到大类中，如果就这样结束，估计很多人会吐槽，因为现实中对产品经理的工作定位，远远超过了以上2点，于是网上有一种从产品的生命管理周期来对产品经理职责进行划分定位的方法，如下图1-1：
产品的生命管理周期分为： 概念化阶段 ------评估产品机会 产品化阶段-------定义要开发的产品
开发阶段---------协调资源、保证开发进度，确保开发出正确的产品
商业化阶段-------与运营和市场团队合作，制定推广策略和产品宣传方案
市场化阶段-------与客服部门沟通，了解用户反馈，升级产品，评估2.0产品机会，循环
进入第一阶段
图 1-1 产品经理职责
从产品生命管理周期来定位产品经理职责的话，可以分为五个阶段的职责，如上图1-1所示，每个阶段产品经理的工作职责侧重点不同，在开发阶段确保开发进度和开发质量，商品化阶段和市场化阶段，产品经理主要的工作是协调公司资源，推进产品进度，了解产品反馈，制定产品推广策略，而这几点都建立在和其他部门的相互配合上，统一可以称之为推动产品目标的实现。
个人总结：从产品生命管理周期来定义产品经理职责比较明确，如果将开发阶段、商品化阶段和市场化阶段的职责进行抽象化，产品经理的职责也可以在原有《启示录》作者观点上的基础上抽象为四大类：
1、评估产品机会
2、定义要开发的产品
3、协调资源、推进确保开发出正确的产品
4、协助各部门，推动产品目标的实现
产品需求的4层关系
互联网产品需求，其实跟以前我们做开发的软件需求基本是类似的，我也不知道是不是大家从那里搬过来的，暂且不考究这个。今天说下产品需求的4层关系; 首先先说是哪4层： 1. 业务需求 2. 用户需求 3. 功能需求 4. 系统需求 看官别着急，单独拉出来一个系统需求是有原因的，如果你不是三五年内的小白产品应该能看懂。
业务需求(business requirement)
什么是业务需求?我觉得是Business Analysis， 就是所谓的
BA吧。不过现在大多数boss或者说创业者不懂这里面具体都是点什么，百度给的定义其实也不是特别的精准，倒是找到一个文库内容，关于业务分析师的定义
这里介绍的很精准。好吧，简单的说业务需求是方案范围，经营范围，或者项目范围。业务分析的东西其实就是一种需求的寻找。 举着栗子说：
业务需求就是写出来，我们是做什么的，电商?还是社交?还是其他平台?我们是不是垂直的，线上的还是线下的?我们依赖什么盈利?我们的业务方向怎么发展?
到这里都是业务需求。
业务的需求往往来自boss或者创业的小老板再或者是你们的某个高层领导。专业一些的会有一些大牛给出商业或者业务分析报告给你。更强有力一些。比自己觉
得做哪个好要靠谱很多 。当然我现在讲的是互联网，其实很多东西都是通用的。 用户需求(user requirement)
用户需求在互联网中的表现大多是在各种场景下，用户想做某件事情所遇到的问题，或所想满足的欲望。用户需求前期是对比，后期是体验。
在软件中的用户需求则不是，软件用的用户需求是在场景下用户的目标以及能完成的东西是什么。这里需要大量的用例，跟场景描述。
用户需求直白的说就是，你的业务规划，有没有人鸟你，大家对这个事儿咋看，你能帮他们解决啥问题等等。其实还是为了确认project scope 是不是正确的 ，有木有搞头。 功能需求(functional requirement)
功能需求是为了满足业务跟用户而制定的。也就是说，在你的业务需求出来之后，你要满足用户在你这个产品上怎么实现自己的任务。业务需求都包括什么呢?或者说细化到哪一步了呢? 举个栗子：做电商要有购物车，要有商品发布。好的，那购物车里面的功能具体是什么，怎么展示?你可能要细节的写出来，购物车可以批量结账，要有一个 单价叠 加的计算，如果有打折，可能还有其他的运算;
商品发布，参数都有哪些，发图片、名称、商品描述、颜色、类型等，如果你是一个很有经验的产品人，在这一步你能为前端跟猴子省下很多很多时间。 系统需求(system requirement) 为什么把这个单独拿出来了，是因为在每个需求下都会牵扯到这个系统需求。在软件中是架构师的责任，在互联网中可以是项目经理、产品经理、技术总监共同完成 的东西。因为它包含的东西太多了，而且过于繁琐与复杂。那什么是系统需求 ? 系统需求是数字控制。还是举栗子说：
在开发过程中，产品时要反复跟各个部门打交道跟交流的，前端、设计、猴子、项目经理、boss。但是有一点，你必须要出的东西其中有一项叫数据字 典，这个 程序员帮不了你。
比如你的用户名长度，猴子的思维是，我的是string，长度你随意，前端的世界是，正则判断下不要乱七八糟的符号就好了，然后不要超过样式的宽度或者超
过了也没事儿我给隐藏了。 那请问，用户名到底要多长? 区间是什么?
这就是系统需求的一部分，因为你要合理的写出来账号，介绍，密码，描述，等等等等之类的一切能键入的规则，你以为这样就完了吗?
再深化一些，你要跟运营部或者市场部，估算出用户成长，在什么时候达到一个什么活跃度等相关数据，以便猴子们可以分库分表或者早点做防备，可能会有人问，
为啥当初不分好呢?
要是当初能分好，阿里巴巴就不用去请oracle的团队来架构自己的数据库了，当井喷的时候你根本想不到是什么时间，所以这些必要的措施跟部署也是需要产
品人来参与的，这会直接影响到产品跟用户的。 如果你做的不合理，你的规划不好，那用户的体验就没有了。 说案例：
你的社交功能需求跟业务需求写，客户浏览自己个人中心的时候会加载很多推送，这一页的数据加载量很多，有可能认识的，可能感兴趣的之类的，好的。没有什么
经验的猴子可能就直接捅给你数据了，功能实现了没错，首页加载慢的要死。如果你能写出来，这里会跨表，跨库，需要一个沉余或者缓存数据表，要不就用分布式
部署来解决。那猴子们会不会能完美的解决东西?
有人说，我是个产品经理，我不懂技术。好吧，你大大小小也是个经理不是么?你的任务就是给公司减少难题解决问题的不是么? 经理也是个管理者不是么?你要操心的问题还有很多，你要涉猎的东西还很多，你的知识面也需要很广。这样你才能是一个合格的产品人。 举报
第四篇：职场培训 产品经理的职责
产品经理的职责
产品经理类似于一个刚启动的公司的首席执行官，他将业务计划呈现给PAC，保护该开发项目的资金。PDT领导对提交的新产品包负完全的责任。通常产品经理在一个或多个功能领域既有管理层又有操作层经验，并有管理过开发项目的经历。产品经理可以来自财务、R&D、市场、制造、技术支持或采购的任何功能领域。产品经理组织项目开发团队，对团队的结果负领导责任并代表整个团队的利益签定提供产品包的计划合同。产品经理富有项目管理经验很重要，应有项目经理的任职资格证书。
产品经理管理项目计划进度、预算、人员配置、资源和报告的制定，他/她负责创建和维护集成的项目文件，评估并管理项目风险，综合决策点材料包和建议书并呈现给PAC做投资决策和评审。
产品经理的职责包括：
1.
建立、支持和领导PDT核心团队
2.
将产品开发作为业务管理系统来用，以驱动跨功能部门的产品开发计划和执行
3.
确保财务、开发、制造、技术支持、采购、市场行销和销售计划是互相耦合的
4.
为所开发产品包制定和管理跨功能部门的计划
5.
从PAC获得承诺
6.
确认和管理所开发的产品包及跨功能部门的依赖性
7.
与PAC共同工作确保所需要的资源的到位
8.
制作和综合项目交付件、预算和时间进度承诺，如项目管理
9.
管理所开发产品包的赢利和亏损
10.
启动项目和保持项目正常沟通
11.
当无法达成一致时做出决策
12.
对整个项目准备工作分解结构图
13.
召集PDT核心组针对项目任命和期望值做沟通
14.
将项目职责分配到PDT核心组成员个人
15.
指导项目操作员(POP)建立项目环境、模板、文件等
16.
需要时借调额外的团队成员
17.
指导PDT核心团队成员同时制定其相应的功能部门的策略和他们各自的WBSs(Work
Breakdown
Structures)
18.
在概念阶段和计划阶段，领导核心组共同合作优化/细化项目WBS到不同的层次
19.
将所要提供的产品包的高层路标图固定下来
20.
共同合作将各功能部门的策略集成进业务计划及该项目的建议书的制作中
21.
在概念、计划和可获得性决策检查点做指导
22.
作出各DCP的日程安排及将业务计划和建议提交和呈现给IPMT的时间表
23.
制定和维护项目计划，确保根据时间表、预算和规格说明书执行各类活动
24.
保证项目完成及业务目标实现
25.
管理由PDT核心组成员履行的处于关键路径上的活动
26.
收集和以文档记录资源、资金需求和承诺
27.
维护集中的集成的项目文件
28.
进行风险评估和制定风险管理计划
29.
跟踪问题直到问题解决
30.
管理项目更改控制
31.
保持适当的业务控制
32.
确保合法的有调整的需求被满足
R&D
PDT
开发代表(研发项目经理)
R&D
PDT
成员关注于所要提供的产品包必需的硬件和软件开发。根据所要提供的产品包的内容和复杂度不同，可能会有一个或多个硬、软件人员是PDT成员，代表所有开发部门作出承诺。
R&D
PDT
成员和系统工程师一起工作，将需求转化为所要提供的产品包的目标，开发产品包的定义、硬件和软件的组成定义，并且按照这个设计开发出产品包。他/她负责创建和维护产品包信息计划(包括记录的保持和保护)、质量计划、产品迁移/转换计划、生命周期结束计划、升级计划、硬件测试计划、软件测试计划、全球化支持(NLS)计划和翻译验证计划。R&D
PDT
成员代表设计者、开发者、测试者、总体、计划者、认证专员、知识产权分析者等，通过项目计划管理他们的活动。
R&D
PDT
核心组成员的职责包括：
1.
按照项目计划保护和管理R&D功能部门的资源
2.
对所要提供的产品包概念进行技术评估
3.
优化/细化业务计划中的开发部分的工作分解结构
4.
开发所要提供的产品包的定义
5.
评估所要提供的产品包的技术风险
6.
拟制业务计划中的的R&D部分
7.
拟制为决策评审点准备的R&D相关的建议
8.
拟制所要提供的产品包合同中R&D相关部分
9.
检查和保护知识产权
10.
如果需要整理出专利档案
11.
和系统工程师及其他PDT核心组成员合作
12.
决定必需的获得物或发展业务伙伴
13.
定义所要提供的产品包和/或技术依赖性
14.
制定NLS(本地语言支持)计划
15.
选择关键器件
16.
规划资产重用CBB
17.
设计、开发和测试产品使之符合规定的需求
18.
通过项目时间表驱动所要提供的产品包的开发活动
19.
驱动测试计划和规格
20.
创建产品演示材料
21.
创建分发/发行和支持计划
22.
第五篇：一线产品经理的工作感想
只是个人的工作心得和所思所想，信马由缰一通，做产品的人能大致看得懂就行了。 没啥铺垫的，直入正题，一块块来：先上一张图
需求文档看不看
当你辛辛苦苦写出来一堆需求文档，跟UED的同学定好交互、视觉、重构;满以为技术会认真对待，但是你会发现，技术同学基本不会看你准备的一堆东西，基本是按照自己的理解来开发，当开发不下去，第一时间也不是看文档，而是看测试用例，或者直接跟产品沟通;基本文档只是QA同学对着写用例。
刚刚开始工作的时候，对于技术不按照文档开发，是比较着急上火的，经历一段时间后，发现重点就好了。产品的本质是保证产品核心功能的质量，保障用户体验，用户端和商户端的功能不能含糊;运营后台、客服后台之类的，保障功能完整和业务流畅的基础上，可以给技术适当的自由发挥;就算是前台页面，多听听技术的意见，让技术同学参与进来;开发过程中，保持沟通，对于技术提出的问题，最快速度的响应。
什么样的需求要写文档?对于功能性、涉及业务流转，状态切换，边界条件灰常多的需求，流程图、交互、PRD一个都不能少;对于非功能性的需求，提升用户体验的部分，文档可以不准备，准备好原型图，然后在上面标注出重点，交付的时候讲清楚。
todolist与优先级
产品在迭代过程中，不断有新的需求，不断有需求被完成，通过list来管理这些需求，整理的过程也是对产品思考的过程，不停问自己，这个需求用户是谁，解决什么问题，是否必要，以及是否必要现在就做?
list的好处就是，可以尽量多的记录所有需求，虽然有些天生就是被砍的命，但是list一堆需要完成的事情，对整个项目组都会有紧迫感;一句话讲清楚每个需求，标明优先级，负责人，对应的开发，开始时间，完成时间，完成状态，让项目组所有人(包括老板)，都知道我们现在有多少事情在做，已完成来多少，接下来做什么。
需求永远做不完，对于优先级安排，平时工作中最常用的就是四象限法，重要又紧急，重要不紧急，紧急不重要，不紧急也不重要，根据项目实际来做判断。
需求会议
2014年都是一周一次迭代，每周都会有下次迭代的需求会议，并不是真正意义上的需求评审，产品驱动的公司，基本就是需求讲解，交付，以及相关时间点确认
需求准备要充分
在需求会议上，面对技术和QA，甚至老大们的挑战，这是正常的，他们会问为啥要这么做，为啥不那么做，甚至直接对你的需求提出挑战：这个东西不靠谱，不可能;拍桌子打板凳的事情也时有发生;唯一避免发生的情况，就是对于需求的准备要充分;不管面对何种挑战，讲清楚数据、用户需要、和竞争对手怎么做的，基本就能说服;一般只要保持平和的心态，不会有大问题。
真有自己无法立即解答的，快速承认错误：不好意思，这个是我没有准备好，会后我再去做详细调研和准备，快速跳过这个问题，继续下面有把握的内容;会后再去完整论证，并把问题描述清楚，邮件给大家;既可以避免冲突，会后大家平和心态来对待，也便于解决。
讲好我的故事
这里应该是讲好用户的故事，为啥叫讲好我的故事，因为产品需要把自己代入到各个角色中;做过几次用户访谈，很多用户描述这样一个场景，我快下班了，拿出点评App搜索附近找吃的;运营说这个这个很烦，我需要这么这么做，其实可以这样就解决了;
客服说，这个信息在这里查，那个信息在另外一个页面，每条记录处理的时间增加多少分钟;
最有意思的是商户端，商户那边有签合同的、店长、负责人、前台、收银，会计，每个人都有可能来用我们的后台，去商户端做访谈的时候，观察他们如何使用点评的产品;
讲需求的时候，先描述用户遇到的困境，绘声绘色，动人心弦;如何做到，代入自己的角色，不要假装用过，而是自己真正使用过程中的痛点，放大再放大，感情方式来打动技术。
描述痛点只是第一步，可以清楚描述，如果这个需求做来，运营效率可以提升多少，节约多少成本，最终转化率预计提高多少，以及ROI(投入产出比)，所有功能点的改进，最后都可以结算为Money，因为钱，会让所有人兴奋，并集中精力来解决问题。
让更多的人参与需求讨论
需求被挑战，会有点不舒服;但是若所有人都表现出对你的需求漠不关心，那才是最难受的。如何让技术更多的参与需求讨论：首先可以挖掘对业务有兴趣的人，多跟他们聊，他们会主动告知他们的想法。一般工作几年的技术比刚刚工作的童鞋更关心;其次让技术有存在感，定时告知他们相关的产品数据，月用户数，月增长量，收入等，根据技术所开发的功能点，细化到此功能带来的数据，以及同比环比数据;最后在Scrum中，计划扑克能够让所有人都参与到需求当中，因为每个人都要评估task的工作量，目前来看，效果还不错。
确定好时间点和相关责任人
Scrum确实是一个好的方式，能够估算出工作量，并且技术自发领取任务，直至每个人工作内容都填充满整个sprint。
在未开始Scrum之前，每周一次需求会议，只是交付好相关需求，由开发主管来指派任务，并定好工作计划表，然后QA同学补充相关测试安排，最后敲定上线时间。
其实不管何种方式，最终的结果导向就是，产品尽快上线，且以最有效、风险最小的方式。
适当地砍需求
产品是不需要懂技术，但是如果能根据需求大致预估工作量，排期更简单;每次我都会提前多准备一些，连交互和重构都准备好，摆出一副不做此需求是誓不罢休的架势;资源充分时，技术童鞋会主动领取需求的，但是当工作都排的比较满的时候，就很难了;所以需求评审时，每个需求的优先级都排的高高的，将用户痛点描述的栩栩如生，如果技术实在抱怨太多，或是总拿51230.com那样的婚恋网站来举例，那就象征性地砍掉一部分，前提是保证核心必须完成，其实当时砍掉一部分，不会一直砍下去，而且心里也会有满足感;其次给技术紧迫感，赶紧完成，后面还有一堆事情呢，即使这次迭代不做，下次迭代也需要完成。
产品开发过程中
保持沟通
在产品开发过程中，技术都是非常有责任心的，会帮你考虑边界条件，作为产品积极响应技术提出来的各种疑问，是维系技术与产品之间很有效的方式。虽然有一些问题，可能是技术对需求的理解并没有产品那么深刻，讲清楚就好了，没有必要上纲上线，因为最终大家的目的都是为了产品，另外公司开始实践的Scrum也对整个团队保持沟通，既是要求，更要成为一种习惯。
认真对待测试用例
测试用例，又是一个保证产品质量的利器;刚开始工作的时候，认为测试用例只是QA同学的工作，第一版本App上线做UAT的时候，发现对着需求文档并不能完整验证完所有需求，但是对着测试用例，所有的主流程，辅助流程，边界条件，非功能性需求，清晰明了，感觉太有用了。所以每次都提前完成需求文档交付QA，QA在技术正式进入研发完成用例文档;在过测试用例时，产品同时参与，避免一些需求理解上的偏差，此外技术同学对着case开发，比需求文档描述更清晰，另外技术同学可以参与部分自测;UAT的时候，也是产品的参考。
需求变更与delay
需求变更是永恒的话题，Scrum中一般是不接受需求变更，其实不允许变更的本质不是需求定板不动，而是对产品提出了更好的要求，从需求调研、准备、设计、交付每一步都需要考虑周全和清楚;即使在要求严格的Scrum中，需求真的不能变更么?如果临时线上bug造成用户无法访问，技术同学是不是要停下手中工作，来排查线上故障呢。作为一个产品，不是神，尽量保证所有的需求都是合理且必要，并且将所有的需求准备工作做到位;如果还不能避免，就要影响甚至说服整个团队来拥抱变化。
正确处理需求变更
需求变更已经发生，那就赶紧处理吧。如果是产品没考虑清楚，用户调研或者数据支持出错，果断向团队承认自己的错误，没有人会责怪一个真心诚意道歉的人;并在第一时间交付变更后的需求文档、交互、视觉、重构等，并跟技术沟通如何以最小的代价，完成此次实现;若技术的工作在本次迭代已经安排很满，那考虑需求的紧急程度，适当情况下，可以放到下个迭代去完成。
若是因为行业或者市场变动，产品转型等原因，直接向团队传达变更的原因，以及接下来的产品规划，让所有人都看到一个清晰明确的目标，技术会有疑问和挑战，耐心解答，通过行业数据、竞品等角度去阐述;遇到老板变更需求，那比较简单，因为老板的需求优先级永远是最高的，但是作为跟技术直接沟通的产品，要认真对待老板变更的部分，若老板频繁变更需求，烦的是技术，会不会以后合作留下影响呢。
关于产品delay
不管产品还是技术，没有人愿意看到delay的;面对delay，怎么处理?换个思路：就算delay了，只要用户还能用，服务照样跑，地球还照样转。如果真的导致用户不能访问，整个技术团队肯定加班加点，不吃不喝也会搞好的。一旦出现delay，整个团队一起来排查delay原因，是需求变更，还是资源没到位，还是项目之间的耦合关系，前面小的改动，导致后面项目的延期，做好每次的总结会议，并在下一个迭代中避免此问题。
目前团队中正慢慢引入Scrum敏捷开发，而本篇总结，大部分是基于小瀑布模式的迭代;需要学习的还有很多，一转眼又过了两个月，正式工作已经八个月，需要走的路还有很多，跟随整个team一起成长。
算是工作总结吧，主要是自己梳理一下，路还长，继续跟着一班牛人加油呗!