1、 ADS的重要性和以及确定方法 明确的目标和产品定位非常重要，这个道理大家都明白，但有两个关键点，其一，如何确定产品的定位和目标，其二，在项目和运营过程中的坚持执行。 如何确定产品的定位和目标，团队讨论可以从三方面来分析： 1） 用户的需求，产品经理就是用户的代言人，必须做最了解用户需求的人，自己要多用多体验，多听用户的反馈，力求找准目标用户群，抓住核心需求。 2） 市场状况，对竞品的体验，了解行业发展状况，有较宽的视野。 3） 分析自身的优劣，我们做这个产品有什么优势和劣势，分析清楚，提早预见问题，准备解决方案。 确定了产品的定位和目标，产品经理就要在团队内说服大家，达成共识，并且在后续的项目以及运营过程中始终坚持下去。 2、 学习能力 公司内比较受欢迎的两种人：懂技术的产品经理，有产品意识的开发工程师，所以产品经理一定要了解技术知识，可以通过自学书籍，向开发同事咨询，以及参加一些技术架构基础介绍的培训课程来学习，最重要的还是要有很强的自学和消化能力，通过每一次的沟通，快速积累基础知识。 3、 团队参与 让一个项目从PM或产品经理事事催促，转变为项目成员参与和自我管理，项目内所有成员的参与和成就感很重要，产品经理或项目经理做为团队的成员，自身要有主人翁意识，主动承担更多的工作，同时要注重营造团队内的全员参与的氛围。比如可以轮流主持晨会，周会，轮流讲需求，出故事卡等，项目过程中也可以组织一些team building的活动，活跃气氛。 4、 从用户中学习 互联网产品的一大优势是，直接服务于终端用户，离用户很近，从用户中常常可以了解到很多真实的需求。怎么从用户中学习，有三个方面要注意： 1）渠道，产品经理要建立用户反馈的渠道，留言板，support平台，建立用户QQ群，产品微博，用户CE等等，很多种方式，要善于利用。 2）每天关注，每天花一定的时间与用户交流，或去看用户的留言及反馈。 3）辨别，面对用户海量的反馈和建议，要有判断能力，遵循的方法也是以产品定位和目标为依据。 5、 关于PK 正确看待PK，产品评审时常常会出现PK，通常是两个原因，一是，信息量不一致，二是，方法论和逻辑不同。所以我们在产品讨论PK时，要积极交换信息量，通过PK，交流，增加自己的信息量，来辅助决策，而方法论和逻辑则是思路的不同，要勇于接受和自己不同的思路，敢于否定自己。 另外，在“挑毛病”的同时，最好是给出建议，不建议仅凭个人感觉就轻易否定，为了PK而PK。 6、 产品经理的心态 产品经理要自信，同时有开放的心态，自信的基础是专业，是深思熟虑，在准备充分的前提下，对自己的能力自信，对自己的策划有信心，说服团队成员对目标达成一致，在反复讨论无法共识时，要果断决策，勇于承担后果。 与此同时，还要保持开放的心态，在听到反对意见时，用心倾听，不轻易否定，不将自己的思想强加于团队。 7、 做减法的能力 手机终端的产品经理更要有做减法的能力，在受限的设备和受限的网络环境下，是否能精准的抓住关键点，给用户最想要的，这和明确的产品定位和目标是分不开的，同时对细节体验把握良好，果断处理。 8、 敏捷实践，细分迭代 小步快跑，快速出demo，在互联网产品中尤其重要，是全部想清楚了再做，还是抓住关键点先尝试，不断滚动完善，显然在互联网快速发展的环境下，后者更合适，落实下来在产品策划中，项目计划制定中，迭代划分中，都需要贯彻。 9、 沟通 项目中的各角色要充分交流，善用各种工具，效果最好的还是面对面，要注意定期，频繁沟通，以确保大家的思路和理解都是一致的，才能最终保证项目的进度以及产品质量。

引用 Smile 的 【UCD年会之助手篇】《挑战Deadline—项目管理的艺术》专场会议纪要 传说中，这是一场“巨头汇聚齐PK”的会议，那仅有的18张入场券让众人趋之若鹜。非常感谢我们的彭毅大哥赐予我“助手”身份，得以荣幸参与此次巨头会议。虽然当天忙到连午饭也没怎么吃，但是能与那么多优秀的产品界前辈交流学习，不亦乐乎。 以下是我整理出来的当天会议纪要，和大家共同分享学习之。由于会议内容涉及到部分不方便公开内容，故以下的会议纪要为所删减版本。(此篇为客观阐述篇，感想篇请见“UCD年会之感想篇”)  【主持人】：与今天早上白鸦所说的比较理想化项目开发流程相比，在实际项目开发过程中，每个公司都有不同的实际情况，导致项目最后无法按照既定的开发流程执行，必定会产生项目的失败。首先请大家说下对项目失败的定义. 莫子：达不到目标就是失败，所以关键是看你的目的是什么。如果说项目失败了，那是因为没有达到我们预定的目的，这个我就称之为失败。 童跃美：不同规模团队的失败定义是不一样的，一个2-3个月的项目失败了，对于大公司来说也许不算什么，但是对于创业团队来说则有可能导致他们倒闭，所以我觉得要根据团队规模和承受能力大小来定义。 盛一飞：项目的失败是在项目运营一段时间后，导致公司的成本极速上升，包括人力、资源等，而最后没有产生结果或是所产生的结果很小，且偏离了我们的方向，则我觉得是失败的。互联网产品很难再一段内判断其是成功或是失败的，但是整个项目开发过程中我们不断矫正，项目所设计的产品结果也许不是最好的，但是在该项目的设计过程中不断进行了调整和矫正。 王旭升：互联网产品迭代的速度是非常地快的，假设我们要开发A产品，目标非常的明确，但是影响它的外界因素也是很多的，这时我们最原始的需求要进行统筹。刚开始的时候，目标不是很明确，但是由于外界的因素，例如竞争对手的成长速度非常地快、后来又有新的东西进来，又或是产生很多的新功能受很多用户的好评，这时需要我们对原始需求进行再定位。对于小项目来说，并不是没有把目标定明确，而是大家都熟悉的一个道理，那就是“已知是这样的前提之下，还是会产生很多的需求变更”。这是很多团队都会遇到的问题。 莫子:我认为这是大目标和小目标的问题，你刚刚所提到的SNS，在我看来，做SNS是个目标，但是我们并没有深一步去想，我们为什么要做SNS，其实我们再想深层一点，我们就是想让用户在一个地方形成一个互动平台。我觉得只是要我们这个大目的是正确的，那个小目标是可调整的。 童跃美：彭毅，我想了解下你们亚运是如何定义失败的？如何判断这个项目是该迭代还是该放弃呢？能和大家分享一下吗？ 彭毅：因为之前是做奥运项目，现在是做亚运项目，应该说最高目标是没有变化的，所以没有迭代之说。由于项目的性质，这些项目必须是要在规定时间内上线的。至于如何衡量一个项目是该迭代还是放弃，我觉得主要是看这个项目的投入和产出比，用一个概念化来说，那就是是否符合用户的需求。 刚刚所说的都很有道理，但是有点分散，我这里就总结一下，我觉得失败可分为以下三种：      （1）完败—就是说这个项目做到一半中途就被取消了，而没有产生任何价值沉淀。      （2）推迟—就是运营时间一而再地推迟。作为一个产品经理，我觉得项目的推迟，在一定程度上就是被认为是失败的。      （3）鸡肋—赶在有效时间内完成，但是所发布的产品漏洞百出，功能很垃圾。还有一种，就是刚刚盛一飞所提到的—人力成本的增加，人力成本的增加而导致公司成本的极速上升。其实可不可以这样想，成本的增加实际就是这个产品本身就没有达到我们的目标。 莫子:这个观点我有点不是很认同，我觉得适当的成本增加只要达到了预期的目的或是超出了我们的预期，我觉得还是可以的。并不是说因为人力等资源的成本的增加就说一定不行的。我最后觉得还是投入和产出的问题。 盛一飞：刚刚我所说的中途取消，涉及到一个决策问题。其实就是我刚开始所说的投入达到了一个他所不能承受的地步。取消，其实就是内部决策把它给挤压了。而产品后来所产生的价值，未必是你之前所说的目标，但是可能有价值，且是可延伸的。有时候有些产品就是因为这样而活了下来的。。。。 莫子:在我看来，中途取消的项目通常都会有价值沉淀的，起码你吸取了经验教训，下次可做得更好。。。。 千鸟：同样一个目地，在不同项目里，它都有不同的优先级。 干文山：我觉得一个是站在公司战略层面，如按照老板需求完成，但是由于市场原因无法上线，站在公司战略层面上是失败的，但是从这个项目来说，是成功的。 黄夷：我觉得彭毅说的鸡肋，是指如果这个产品我自己研发后我自己使用都觉得不行，我觉得这个产品就真的是鸡肋了。就是说你自己作为用户角色去用你自己产品的时候，这个产品是否失败，你自己心里都已心中有数的了 千鸟：我的理解，推迟和鸡肋是有关系的，有些团队他不想产生鸡肋，所以把项目推迟了。只不过每个团队都有自己的余地，有些团队可接受，那他就按时推出；如果有些团队精益求精，不可接受，他们宁愿推迟也不出鸡肋。 盛一飞：所以我还想说刚刚涉及到的决策，其实产品是否失败，我觉得最最终还是要看团队怎么对它它产生出来的东西。如果他们坚持就是完美，如果它放弃就是完败，如果把它丢在一边就是鸡肋。 莫子：我觉得这个还是目标问题，你的目标是按时完成的，和你的目标是追求最好的产品，是完全不同的。因为是两个不同的目的，所以达到两个不同的结果 刘云天：我们有的是站在产品设计角度、有的是站在产品运营角度，又或是项目经理又或是老板角度来看这个问题的。可能老板认为他要的那个项目按时上线就是达到目的了，而对于你自己来说，想做得更好。所以失败的定义，我们和老板的定义不一样。   【主持人】：国外有家著名数据统计公司专门对IT领域的项目管理进行调查，1994年的时候，有31%的项目是完败的，达到预期目标成功的是16%；而2006年，是完败的项目则下降到19%，达到预期目标成功的项目则提升到35%。也就是说在这12年间，经过项目管理体制的改善和提升、以及管理工具的进步，使得我们项目成功率大大提升。刚才项目失败的定义只是抛砖引玉，接下来想大家分析下导致项目失败的原因，请问在座哪位愿意分享下自己项目失败的例子？以及你们的绩效考核是如何进行的？ 千鸟：我分享下我之前接触过奥美的一些情况，他们比较具有代表性。产品经理是一个level很高的职位，而往下，一个产品经理下面有N个项目，就是一个产品经理会拆分成N个项目同时进行，也就是说产品经理和项目经理是完全不一样的。 刘云天：我来举个例子吧，我就不说是什么项目了。想说明“越是没有问题的项目，却是越有问题的”，案例是这样的，刚开始的时候，该项目很好，且知道该项目的人会越来越多，项目也会越来越大，服务器也会越来越多。但是后来有一天，服务器挂掉了，造成很大影响。后来我问主管服务器的人为什么不去找相关人，他说不知道该找谁来负责此事故。就是这样，当所有人都觉得没有问题的时候u，却在上线的时候挂掉了。 盛一飞：在我们支付宝里，最好的产品经理当然是懂得技术的。产品、设计、技术都懂得的话那就最好。项目经理是个很好合作的，项目经理不是一个传声筒，有些事情你可自己做主，而不是都得等着他们来讨论。 千鸟： 在我工作经历里，好的项目经理需要一定的复合背景。他是可找很多人来帮他，但是这个过程中要消耗成本。项目里每增添一个人，沟通成本都会翻倍。项目经理应该有一定的方法形成自己独特的知识体系。 彭毅：我之前碰到这么个小项目，老板直接找产品经理进行修改，可是一段时间后，产品经理还没修改，老板就直接找另一个技术进行修改，最后导致出错。这个可能和甘冈刘晓天说的案例有点类似，沟通问题。 曾鸣：今天彭毅请我们来，主要是想我们分享一下经验和经历，那我就说些QQ邮箱的东西吧。QQ邮箱团队里有两个明确的职位，一个是产品经理，一个是项目经理。产品经理主要是和用户沟通交流、项目需求的制定，而项目经理则是负责研发的进度，和保证产品的上线执行。只要在称得上是项目的东西，都有这两个职位。项目经理也许不是一个所谓公司正式任命的“经理”，他只是一个很普通但有一定资历的开发人员。  例如邮件的会话功能，该虚拟项目组总共是4个人，所以我对今天早上白鸦所说的那个“小”字特别有感触，我觉得他的那个“小”的定义和我们的想法是一致的。我们的虚拟团队一般都比较小，小到什么程度呢？我们大部分的虚拟项目组一般是3、4个人，其中包含了一个产品经理，一个项目经理，一个UI，那么这3个人就负责把这个项目全部完成。项目需求的提出和引导，由产品经理来做，但是真正的方案确定必须是整个团队的人来共同决定。 我们强调团队合作，而不是个人英雄主义。即使你的产品经理很牛，但是UI有他专业领域的知识，UI的大部分决策是由UI来定，当然产品经理也可给建议，但是最后出来的决策必须虚拟团队共同商量沟通好后的结果。 沟通很简单，我们采取的都是面对面沟通。我们觉得这是小团队最高效率的沟通方式。 项目一般会采用“滚动”方式推进，“滚动”可以保证项目尽可能朝着正确的方向前进。我们在实现了最基础的产品功能后，先让一部分人（我们觉得可能需要此功能的那部分人）先用。产品上线后，产品经理会收集用户意见、提出项目下一步的用户需求，然后反馈给项目团队。大家通过沟通觉得用户需求合理，那么我们就去做，做了之后就接着放出去，继续收集用户新的意见，继续根据用户的建议进行产品优化。这个过程就是迭代。总之这个虚拟团队不断地围绕邮件会话这个功能不断地迭代下去，直到这个邮件功能得到大部分用户认可为止。那么这产品经理可以跳到另一个项目区了，但是产品经理还是要一直跟进这个产品，实行“产品终身制”。 产品经理主要是跟进用户反馈、数据分析、数据平台的搭建、数据模型等，且产品运营对整个项目的运作是非常重要的，产品经理必须用心跟进。项目经理更多的是控制技术的开发进度。但是一个项目的成功，必须是团队共同合作的，在我们团队里，UI人员说话的权利是比较大的，我们非常尊重UI人员的意见。 我们欢迎不同的意见，但是项目组内要沟通好。我们虽然没有晨会、没有日报，但只要有需要，随时都可以在一起面对面交流，然后通过邮件将沟通结果周知项目组内。 在此，做个广告，QQ邮箱目前在产品、运营、UI方向急需人手，如果在这些方向有兴趣的同事，欢迎与我联系加盟。 莫子:我想提个问题，你们一个UI人员就把交互、视觉、页面架构做完呢还是下面还有一个UI组？ 曾鸣：我们的UI人员一般都是有交互、视觉、页面的实现能力的，当然，这个UI人员后面还有一个UI组，UI组内部也会有设计和实现方案的讨论。但是我们没有将UI的职责和岗位分得那么细。 莫子:你们是专人专项呢？还是多个人同时负责多个项目？ 曾鸣：我们的项目经理和产品经理可能同时肩负多个项目在身的。 莫子:接下来我补充一下网易邮箱的经验吧，我们的项目是分年度、季度、月度计划的，但是和曾鸣刚刚所说的一样，都是有个项目的优先级的。但是很多时候会有忽然的项目插进来，例如丁磊忽然打个电话给我说要做某个项目，当这个忽然项目和我们整个计划大方向是一致的话，该忽然项目的优先级是比较高的，而合计划大方向不是很一致的话，我们就会把它推迟或是延后。 另外一个，说到业绩考核的问题，我们之前采用的是“50%-50%”的做法，就是我下面的产品人员，我会对他进行50%的绩效考核，而另外50%则是由他的项目组长来定的。后来我们变成了100%都是由行政主管来评定，但是这之前我会和他项目组的组员进行沟通，看他们的表现如何。不过话说回来，哪种绩效考核的方法更好，我们这边也正在进行探讨。 干文山：刚刚听曾鸣说，一般是3-4个人一个小项目，如果小版本出不来，那大版本是否也出来了呢？也就是说单个项目之间存在 –>–>–> [...]

　　单位的一次内部培训，以下是总结： 　　± 凡事预则立，不预则废。好的计划等于成功了一半。项目计划在项目中的作用是不言而喻的，没有计划就没有基准，就可能随波逐流。项目计划是指导项目执行的依据，也是衡量项目组绩效的基准。制定项目计划的过程能够理清项目各项要素。只有项目目标明确、计划步骤清晰，有助于项目的顺畅开展。 　　± 项目计划三步走方略。总结一个，实施一个，筹划一个。及时收集并总结前一阶段项目计划执行情况;及时调整和落实当前计划中的时间、资源等关键因素和实施方式;根据情况变化重新调整下一步中计划，并详细制定下一周的工作日程安排。 　　± 项目计划需要工具支持。目前有多种项目计划技术和工具，甘特图、里程碑、WBS等是项目经理比较常用的几种类型。但也有计划更新麻烦、计划通知或展现不方便等问题，期望有便捷、易学、好用项目计划工具出现。 　　± 制定计划要考虑项目风险。项目风险是直接影响计划执行效果的因素，不考虑风险的计划本身就不是合格的计划。风险管理计划应该是项目管理计划中一部分;已经识别的项目风险，必须在项目计划中体现。对那些险风级别高、风险一旦发生会对项目影响严重的工作，项目经理必须予以关注。 　　± 重视项目计划的沟通和确认。制订计划需要进行必要的、充分的沟通。计划不完整、不合理，将导致项目计划是很难执行;制定的计划不被认真执行和有效监控，也难以实现预期目标。与各方确认项目计划，一是防止项目的任务遗漏，以使计划比较完备;二是计划获得参与者得具体承诺并具有层次性，有总体的目标计划，也有大家可以参照执行的具体内容。