本文目录一览：
互联网产品经理职业介绍
因为成为产品经理，能学到非常多的知识，在不同的层面
产品经理软技能：
个人魅力：包括沟通能力，领导能力，愿景能力，感染能力，审美能力等等；
产品修养：产品修养包括混迹产品社区，运营社区，优秀产品群；
互联网修养：了解互联网现状，跟踪互联网热点，跟踪互联网前沿，混迹互联网社区。
项目管理
产品经理的一个重要角色是项目经理，产品经理需要对整个项目的结果负责，包括按时交付，合格交付，成本控制。
项目经理需要熟练项目的5大过程组和10大工作领域，对于互联网产品经理来说，主要内容包括：
项目沟通：沟通是互联网开发中产品经理最重要的工作，包括和上级，开发人员，运营人员等等；
总体进度计划：项目的总体进度，例如产品设计，UI设计，各个模块开发，测试进度，部署等等，产品经理必须把握整体的进度，针对节点进行审核；
开发详细计划：开发详细计划是总体进度计划的一部分，一般来说开发计划是技术经理维护，但是产品经理必须进行整体把控；
项目控制：项目干系人，风险，进度，质量等等控制。
协助推广
产品开发出来必须推广到市场，否则产品就是一个实验品。产品经理不需要完全负责运营推广，但是必须对运营人员提供必备的支持。
基本工作如下：
基础运营数据：获取产品的基础运营数据，例如下载量，用户量，支付金额，留存；
埋点：埋点的一种获取产品运营数据的重要方法，他可以分析页面点击，页面转化等等；
业务数据：业务数据例如订单情况，售后订单，销量等等；
竞品分析：和市面上相似产品对比分析；
Swot分析：了解本产品的优势、弱势、机遇、挑战。
迭代开发
第一个版本做出来后，产品进入迭代开发阶段，一般迭代周期是2个星期；迭代开发就是将从产品规划到运营过程进行浓缩，每个迭代周期开发少量的功能。
基本的工作如下：
收集需求：收集产品的需求，哪些需求进行迭代开发；
需求排序：针对需求进行排序，高优先级的尽快开发，优先级低的稍晚开发；
细节功能设计：第一个版本的功能进行细化，例如效果细化，交互细化等等；
迭代计划：维护整个迭代过程的项目计划。
根植行业
产品都有很强的行业属性，必须熟悉本行业才能设计本行业需要的产品，否则就是空想。
我们需要了解行业现状，熟悉行业痛点，熟悉行业热点，并且还得了解相关行业，此外需要熟悉相关的法规，道德，加入行业圈子，多逛行业论坛。
个人魅力
上述讲的是产品经理硬技能，下面介绍一下软技能，软技能更多的是个人的修养问题，但是这些会影响到产品经理的整个职业生涯。
个人魅力包括个人领导能力，沟通能力，愿景能力，洞察能力，审美能力，感染能力。拥有强大个人魅力的产品经理才能成为整个产品的领导者，才能激励整个项目成员，提高团队效率。
产品修养
产品经理需要提高产品修养能力。
产品修养包括：
与高人为伍：有时高人的一句指点胜过你苦思冥想一个月，产品经理需要向前辈，向领导，同级组织成员请教，请教他们你不熟悉的内容；
与实践者为伍：不要和空想者为伍，而是和实践者为伍，产品的使用对象均是实践者，实践者的想法将会提高你整个产品的境界；
产品社区：例如产品壹佰，pmcaff，多看一下帖子提高自身修养，此外多加入一些QQ群；
运营工具：例如应用雷达，酷传，APP annie，ASO 100，百度指数等，运营工具可以用来分析产品的运营数据。
互联网修养
一个互联网人，必须熟悉互联网，有一定的互联网修养，多看新闻，多参加一些沙龙，提高自身的互联网修养。
了解互联网现状：熟悉当前中国和世界上优秀的互联网公司，多了解互联网当前现状，例如阿里巴巴，腾讯，百度，小米，华为，360等；
跟踪互联网热点：当前互联网热点，例如项目热点，投资热点这些，可以查看36kr，虎嗅，这些社区提高了互联网热点现状；
跟踪互联网前沿：例如vr/ar，物联网，智能设备等等；
大数据平台：常见的例如易观数据，talkingdata，这些互联网大数据平台会提供部分免费的行业分析报告，了解互联网大数据对产品整体把控有一定的帮助。
如果需要学习，可以看下这几个软件：
1.脑图工具：百度脑图
2.文档共享：蓝湖、Axure等软件
3.项目管理：jira
如何管理好一个产品技术团队
团队管理的事情很多，尤其当团队规模更大时，如产品研发、市场支持、业绩考核、日常沟通、学习培训、工作氛围等，以及更多的日常琐事，如果没有一个好的管理思路，团队管理者往往被弄得手忙脚乱，不知所措，成天累得要死，还得不到团队的理解和认可，或者团队也被折腾的很疲倦。如果整理一下，我觉得可以把技术团队的工作归纳为三个“力”，即团队的凝聚力、战斗力和成长力，重点做好这三件事，会使团队管理工作事半功倍，得心应手。
随着现代项目日益复杂和行业跨度越来越大，技术团队的活动往往需要靠团队作战的方式，单枪匹马的时代已逐渐远去。拥有一个好的团队，是工作成功的一个重要的保障，因此团队管理和建设是团队管理者的一个重要工作。
所谓凝聚力，可以理解为团队成员的向心力、对团队目标的认可和共识程度等。在任何时候，管理者都应该能确保团队成员对团队的战略目标达成共识，使大家都用共同的目标；确保团队的认识是一致的，都能自觉主动心甘情愿的为目标去努力。“一切行动听指挥”。要保证团队有凝聚力，需要管理者能做好战略沟通和目标沟通。
所谓战斗力，可以理解为团队的执行力了。三分战略七分执行，说明执行往往来的更重要。在技术团队中，不缺少聪明的人才，不缺少高明的点子，也不缺少高手，但整个团队的执行力如何，是影响整个事情的进展。团队如果能踏踏实实的把东西做出来，按时交付出来，远比其他都要重要，现在的“敏捷开发”提倡的也就是这种思想。另外一种团队的战斗力，就是团队具有突击能力，比如当遇到紧急项目时，只要一声令下，大家就能各就各位，能都够加班加点，不怕辛苦，在预期时间把项目搞定。
所谓成长力，可以理解为团队的学习和自我学习能力。团队要发展，要有长足的发展，那么团队必须要有学习和成长，不断吸取新知识，不断创新，不断改进工作中不好的地方，不断提高工作效率，将技术最高效转化为生产力。团队的不断成长，才能使团队有能力迎接新的任务，有不断的创造力。一个不善于学习的团队，一个不成长的团队，终究会因时代的进步淘汰掉，终会因项目的时间积累而把团队拖跨。
凝聚力是思想，战斗力是行动，成长力是后盾力量，三者很好的结合，就能是团队管理工作变得有序有效，团队也将成为优秀团队。那么，如何提高凝聚力、战斗力和成长力，每个管理者、每个团队的情况都不通，可以采用的办法也不同。不管采用什么方法，管理者时刻需要对这三个“力”的情况不断检查，不断改善。
产品经理常用3个思维模型+10个技能+3类工具
最近部门有一些新人产品经理加入，在与其交流的过程中发现其产品基础知识不够扎实，故整理以下内容希望能够对其有所帮助。
产品经理是一个产品的总体负责人（原则上如此，但在实际操作中很多产品都是功能性产品，但不管如何我们还是希望给自己一个更高的定位），通过价值分析、需求分析、项目管理以及产品运营等方法使得产品能够为客户提供价值，从而为公司的战略目标的实现提供载体。产品经理需要贯穿整个产品的生命周期，并能够在各个阶段做出正确的决策，保障产品目标的达成。在执行层面产品经理需要能够完成产品开发所需要的各种资料、文档，我们能够把需求通过一定的技术手段转化为可开发的系统功能；在管理层面，我们能够对所有的需求进行优先级的划分，能够更具团队的资源情况制定产品实施计划，能够协调团队中的所有资源为产品目标的实现而努力；在领导层面，我们可以通过专业的分析方法，判断产品价值的真伪，把握整体的产品方向，我们还要能够创造开开放、交流、价值优先的团队氛围，能够让整个团队良性运转。
产品经理是一个离CEO很近的角色，即使我们没有那么高的薪资、权力，但我们需要有CEO的视角去思考产品的问题。产品经理应该是整个团队的中场，产品实现的过程中我们会有很多的任务，每个任务就是一个球，我们能够通过合理的组合、协调把球射进门解决掉，最终让我们的球队赢得比赛；产品经理也是整个产品的第一背锅者，任何产品瑕疵、错误产品经理均需要能够负起责任，并能够直面这种问题，找到方案解决它。
MVP即最小可行性产品，互联网行业是一个高速发展的行业，一起以用户为中心，在这个背景下要求我们能够快速且低成本的识别哪些客户的需求能够大范围推广并获得用户认可。而MVP即是这样一种思维，MVP讲究的是最小可行性，我们需要为用户提供可用的产品，但产品可以是很初级的功能，例如：微信一开始只有文字或语言发消息的功能、滴滴一开始只提供一种打车的模式、淘宝最开始也只有浏览商品并下单的功能。我们在落地MVP思维的时候最怕就是在需求上没有闭环，例如：我们做微信只考虑了发文字、发语音，而没有考虑发消息和接受消息的用户之间的关系，虽然用户最核心的需求只是要一个工具，但是如果我们不考虑这种熟人之间关系的背后逻辑，那么微信也就不可能非常清晰的定位为熟人社交工具；同样滴滴如果只考虑了乘客找车的需求，而没有考虑司机接单和分成模式的话，那么也不可能把完整的打车需求实现闭环。正如网上流传的一张图：
MVP思维中最难的是对“最小”进行准确的定义，很多的产品说是在做MVP，实际实在做一个一个的轮子。
其次，我们要讲下敏捷思维，敏捷是一种开发的思维，其核心是要求团队能够不断的交付价值，并能够快速的应对由于不确定性而引起的需求范围的调整。在开发实施的过程中，我们能够让团队成员充分的理解我们产品的目标、形成良好的沟通氛围还要能够充分的调动成员的积极性使其能够自发的思考自己如何为产品目标的实现做出贡献。一个标准的敏捷开发的工作流程
强调敏捷思维还有一个原因是范围、进度、质量之间的矛盾关系，由于在不确定的环境之下需求范围是不断变化的，而我们在这种不确定性中最好的做法就是在较短的时间能能够不断的交付有价值的产品功能，所以我们使用敏捷开发方式，以固定的时间周期为基准，在团队能够相对固定的情况下，选取最优价值的需求进行开发，以求最大价值的交付。
最后我们要讨论下系统思维，系统思维要求我们在考虑产品设计是需要从结构性、一致性和可扩展性等角度考虑功能的设计，优秀的系统一定是要能够具备演化能力的。人是一个复杂的系统，人体的结构大概可分为如下几个部分：细胞——组织——器官——系统——人体。人体的这种结构能够让复杂的系统得以很清晰的展现，让复杂得以控制，让我们对这种复杂系统进行知识输出时能够条理更清晰，更好的进行知识的传递，也让我们在发现问题时能够快速的找到原因并提供针对性的解决方案。其次我们要让同一个层级的内容保持一致性，混乱制造麻烦，让事物看起来不那么美观，看下如下两种图：
秩序产生美，我们在做产品设计时同样要保证我们功能、交互、视觉以及文案上的一致性，而这种一致性会给用户带来专业以及美的感受，让用户能够感受到我们作为产品设计者的诚意。我们在设计系统时还需要考虑它的扩展性，任何一个系统一定要具备可演化性，在功能设计上我们需要进行业务抽象，能够让我们设计的功能满足更多的业务模式，例如：我们在设计商品模块时把分类、属性、商品、SKU分别进行抽象，商品对象中只保留定义商品所需的最小属性集合，而把不同业务所需的属性设计为单独的分类、属性模块。除了在功能上我们需要预留扩展性外，我们在交互的层面统一需要预留扩展性，多用竖向导航而少用横向导航，属性导航可用空间扩展性更好；列表采用固定高度、固定列以及动态表头的设计，可以很好的满足各种极端情况以及用户需求。系统思维还要求我们能够从局部推导出整体、也能够从整体分割出局部，我们要能够理解在这种局部和整体之间还存在一些其它要素需要进行管理。
聊完了产品经理最重要的一些思维方式后，我们在说下产品经理需要具备的一些关键技能。
在产品经理的日常工作中，我们通过需求调研收集来的需求往往是这样的：
1、我们需要一个小程序，能够在上面卖货
2、我们想要一个好用的电商系统
3、客户在我们平台上下单需要上传一定的资质
4、我们需要在平台上提供账期支付的功能
拿到这些需求之后我们需要进行两步操作：价值分析和需求分析。需求分析，保障我们能够把需求转化成具体的系统功能；价值分析，能够让我们理清楚需求真实的意义或目标。需求分析是不分需求大小均需要进行，而价值分析往往是在项目初始阶段且需求实现所需投入的成本较大时才进行。下面我们先从需求分析开始讲起。
1、需求分析
在需求分析的过程中，我们经常会涉及到以下几个步骤：业务流程分析、用例分析、业务模型分析、功能结构设计、页面跳转逻辑以及页面原型和规则设计。
1.1 业务流程
业务流程分析主要的目的是弄清楚我们需求中涉及的业务是怎样的，我们需要明确涉及到哪些角色，每个角色在流程中承担什么职责，需要什么要的输入并输出什么东西，还需要理清楚角色之间的关系，常见的业务流程图如下：
一般我们会用泳道的列表示角色，行表示业务的阶段，在这个阶段我们不必考虑系统功能操作是如何完成的，我们关注的核心是业务（业务即指人们为了交付价值或提供服务而开展的工作）.
1.2 用例图
用例分析是我们对角色职责的细化，并能够对角色的职责进行功能化，能够让我们对所需要设计的系统有一个全面的评估，常见的用例图如下：
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，是从外部使用者的角度看的一种系统蓝图。
1.3 业务对象分析
对业务我们还需要进行抽象建模，我们能够对业务中涉及的对象进行抽象，并能够描述清楚各个对象的关键属性和对象与对象之间关系，业务建模我们一般从业务需求中抽取名词作为对象，而有些对象则需要我们自己通过逻辑推理设计出来，常见的业务模型分析图如下：
1.4 功能结构
通过我们对用例和业务模型的分析，我们对整个系统有一个比较宏观的概念，但用例、业务模型都还是一些比较抽象且呈点状功能描述，我们需要把这种点状的描述串联起来，这时候我们就需要对整个系统的功能进行结构化分析，我们一般把以业务对象为核心组织功能，而功能则来源于各个角色的用例，进行分类整理后我们可输出整体的功能结构图，如下：
1.5 页面跳转逻辑
在有了功能结构图之后，我们需要站在使用我们系统的用户角度考虑，每一个页面、弹框是怎样的，以及他们之间的跳转关系，表达这种内容的文档我们称之为页面跳转逻辑图，如下：
在制作页面跳转逻辑时，我们要以使用者的角度出发，能够清楚的知道哪些页面是用户可以可以直接进入的，哪些是过程中必须出现的页面，这张图就是我们用户使用产品的地图。
1.6 产品原型
最终我们需要输出的是呈结构的产品原型文档，我们需要对每个页面、弹框进行详细的设计，我们定义每一个可见的页面中的元素，以及用户操作这个页面或弹框之后对系统的影响，我们也需要考虑各个页面的极端情况，例如：无数据、有数据、无网络、操作异常等。我们需要对页面中的每一个元素、用户与系统的每一次交互进行定义并把业务规则梳理清楚
需求分析其核心目的是能够让我们准确、详细的表达我们想要设计的产品，我们需要对我们产品需要完成的目标进行整体的分析，也许对完成目标的过程中的工作步骤进行说明，还需要对过程中的基础条件、限制规则、异常情况处理方式进行全面的考虑，只有如此才能保障我们设计出来的产品可运行良好。
说完需求分析，我们还需要讨论下产品的价值分析，价值分析主要是保障我们目标的正确性，严格来说我们应该是先完成价值分析，在进行需求分析，但价值分析往往属于产品经理较为高阶的技能，所以我们放在后面进行说明。
2、价值分析
任何产品我们都需要投入资源进行开发，那为了保障我们资源投入的产出，我们需要保障我们产品目标的正确性，价值分析就是让我们通过严谨的分析保障我们目标的正确性。
价值分析中我们主要介绍以下几个工具：SWOT、商业画布、竞品分析（商业角度的竞品分析、功能角度的竞品分析）、行业分析（波特五力分析）。
2.1 SWOT
SWOT是我们做价值分析的一个最常用的工具，我们能够通过SWOT对企业、产品进行全面的分析，SWOT主要从内部的优势、劣势，外部的机会、威胁四个角度对事务进行研究。
优势 ，是组织机构的内部因素，具体包括：有利的竞争态势；充足的财政来源；良好的企业形象；技术力量；规模经济；产品质量；市场份额；成本优势；广告攻势等。
劣势 ，也是组织机构的内部因素，具体包括：设备老化；管理混乱；缺少关键技术；研究开发落后；资金短缺；经营不善；产品积压；竞争力差等。
机会 ，是组织机构的外部因素，具体包括：新产品；新市场；新需求；外国市场壁垒解除；竞争对手失误等。
威胁 ，也是组织机构的外部因素，具体包括：新的竞争对手；替代产品增多；市场紧缩；行业政策变化；经济衰退；客户偏好改变；突发事件等。
2.2 商业画布
商业画布是创业者创业的一个商业模式设计工具，能够从价值、客户、渠道、财务、资源等能不同方面考虑如何设计商业模式，我们虽然不需要进行商业模式的设计，但商业画布还是可以成为我们理解自己所在公司商业模式的一个非常实用的工具，我们在公司内部能够更好使用商业画布进行分析，通过对公司商业模式的分析我们能够理清公司整体的业务脉络，能够清楚的知道那条业务线重要、那个部门是核心部门、公司产品和核心客群是谁，而这些都是我们在做产品决策时的重要依据。常见的商业画布如下图
包含了九个要素：重要伙伴、关键业务、核心资源、价值主张、客户关系、渠道通路、客户细分、成本结构、收入来源。我们根据所在公司实际业务的情况填入就可对整体的商业模式有一个初步的评估。
2.3 竞品分析
竞品分析一定是产品经理最常做的工作之一，但竞品分析也是最难做的工作之一。产品经理常做的竞品分析分为两大类：商业角度的竞品分析和功能角度的竞品分析。商业角度的竞品分析能够帮助我们理解竞争对手公司的战略，并找到与竞争对手竞争的策略。我们需要从竞对的发展过程、产品形态、商业模式、核心客群、财务情况等方面进行全方面的研究，而这些研究的资料主要的来源渠道可以是百度、企业网站、企业财报以及第三方研报机构（提一下鲸准是个很好的第三方机构），最终我们能够清楚的了解竞争对手它发展的每个阶段所采取的策略、重点打造的产品以及获得的收益。而功能角度的竞品分析则是我们大部分产品必备的技能之一，互联网或软件行业发展了这么多年，基本上很难再有巨大的功能创新，更多的是功能的改良，所以我们自己在设计产品时如果对需求把握不准，那么做一次功能角度的竞品分析一定能够让我们找到很多灵感。而这种竞品分析需要我们直接使用竞品的产品功能，完全把自己当作竞争对手的客户去使用产品，我们需要理解这个产品功能实现的目的、逻辑、效果以及用户使用的心态，而且我们需要同时使用多个竞争对手相似的产品功能，只有通过这种大量的体验、对比才能加强我们的产品感，让我们能够设计跟符合用户使用体验的产品。
2.4 行业分析
最后我们再简单聊下行业分析，通过行业分析能够让我们清楚的了解所在企业的定位，也能够清楚的知道企业未来发展的前景如何，是否能够设计一些创新的产品帮助企业获得提升。行业指的是能够提供相似的产品服务的机构及业务的总称，同一个行业中的企业生产的产品、服务具有很强的替代性。所以我们可以从自己所在企业提供的产品、服务的角度定义所要分析的行业。然后我们需要对整个行业的发展过程进行梳理，能够清楚的知道当前这个行业所处的阶段，一般一个行业主要分为如下四个阶段：创业期、成长期、平台期、衰退期。在不同的时期我们需要使用不同的竞争策略。同时我们还需要清楚我们所处的行业的特性，对于不同特征的行业也会影响我们的竞争策略。
对行业的分析还有一个使用特别广泛的工具：波特五力分析，这个模型认为，所有的竞争的规则都包括在五种竞争力量内， 这五种竞争力就是企业间的竞争、潜在新竞争者的进入、潜在替代品的开发、供应商的议价能力、购买者的议价能力。这五种竞争力量决定了企业的盈利能力和水平。
脑图工具是一种帮助思维结构化的工具（又称思维导图），脑图工具天然具有层级性，能够帮我们快速的理清事物的结构。在确定一个主体或问题后，我们可以从不同的维度对其进行分解，常用的维度划分方法有：时间/步骤、相同性质的分类、人物/角色、系统结构或其他常用的分析模型。脑图工具用途十分广泛，以下我们主要介绍脑图工具在产品工作中的使用场景。
产品的功能结构分析，任何一个产品它都是成结构性的，从上往下依次可分为：产品-模块-菜单-页面-功能（字段），这种结构天然适合使用脑图进行表达。脑图除了能够提供结构性的表达方式，在这个工具中还提供了很多的关联、标签、注解等功能，能够让我们不局限于一个维度的结构梳理，而可以进行跳跃式、多维度的结构梳理。常见的脑图工具有：xmind、幕布、百度脑图、MindManager、亿图等，现在也有很多综合性的工具能够提供脑图功能，例如：印象笔记、ProcessOn、石墨文档、语雀等
流程图工具一定是产品经理最常用的工具之一，通过这一类的工具我们能够会支持业务流程图、用例图、业务模型图等，流程图工具一般都提供
原型工具没什么好说的，使用最广泛的一定是axure，其功能之强大亦不须我在多言语，而近些年对于移动端的产品原型设计也有许多特定工具，例如：墨刀、xiaopiu等，其体验也是愈来愈好了，简单容易上手，但对于较复杂的系统（企业级）还是使用axure更好。
至于其它的像是word、excel、PPT等文档工具自然不必多说，特别是PPT的使用是我们通往更高阶产品的必备技能。总体来说工具是为了提高我们的效率，我们千万不要让工具限制我们的想象力，也不能因为工具而影响我们的产出。工具如果影响我们的工作效率，那么我们还不如放弃使用工具，转而使用最原始的纸和笔。
在最后，还需要着重强调作为一个产品经理我们必须要具备良好的沟通表达能力、快速的学习能力以及自主调节心态的能力。这三种能力是产品经理最底层的能力，若不具备这三种素质基本上是不可能在产品岗位做的长久、拔尖的，而大部分时候这三种能力是不可习得的。
以上是我们对产品经理需要掌握的技能的一个汇总，产品经理是一个复合型岗位，其门槛之低、上线之高是绝大部分岗位不能比拟的，但是在产品经理发展到当前这个时期也基本上处于一个平台期，竞争相当激烈，阶层也逐渐固化，低阶的产品经理想要突破上升的通道越来越窄，而顶尖的产品经理会有更多的资源让其做出更伟大的产品。
招投标中怎么体现公司的项目管理能力
认识项目管理
美国项目管理协会主席保罗说：“在当今社会，一切都是项目，一切也将成为项目。”项目，是在一段时间内为完成某一独特的产品或提供独特的服务所进行的一次性努力的过程。只要有目标和过程，就可以成为一个项目。譬如：设计开发某一产品功能、房屋装修改造、结婚的婚礼筹备等都能称为项目。
项目管理，就是在项目活动中运用知识、技能、工具和技术，以便达到项目要求，其目的是满足和超越项目干系人对项目的需求和期望。项目管理从本质上来说，就是面向目标的，所有的方法、行动都是为了达成目标而服务的。
互联网公司的项目实践
早期或初创的互联网公司，产品经理和技术开发几乎承担着多种角色的工作。产品经理除了产品方案设计以外，还做交互设计、产品测试以及项目执行的整体协调推进工作。技术开发人员除了做程序编码实现以外，还做系统测试以及测试完成后的上线部署。
实际上，从标准规范的人员角色分工来讲，交互设计是交互设计师的工作范畴；系统测试属于测试工程师的工作范畴；上线部署属于运维工程师的工作范畴；项目执行的整体协调推进，也属于项目管理的工作范畴。当那些早期或初创的互联网公司的业务规模越来越大、项目越来越多时，一个人兼任多种角色，就会感到力不从心，必将影响项目进度和节奏。
以中国互联网行业里知名的A公司为例，A公司的W事业部在最早期的组织架构中，会有独立的产品、UE、UI、页面制作、前端、后端、测试等部门，当时没有专职的项目管理人员。项目管理工作多数是由产品和技术部门的负责人来承担。这一阶段尚未形成系统的项目管理流程，因此相关项目工作没有统一的依据，管理较为粗放。项目负责人的界定也不清晰，有时候项目出了问题也难免发生互相推诿扯皮的情况。后来项目执行中问题不断暴露，又得不到快速有效的解决。对项目管理的需求，就变得日益强烈，业务线的领导意识到需要从全局高度统一对项目做管理。主要体现在：需要确保项目资源合理利用、明确项目成员的角色分工、制订合理的项目计划并推进执行。看似非常简单的要求，却是A公司W事业部在项目管理方面的起航。
W事业部为了增强其项目管理能力，成立了项目管理部（PMO），直接向业务线的负责人（高级总监级别）汇报工作。当时在产品、设计和技术类部门，形成了如下形式的人员角色划分（运营和市场类部门，不做介绍），如图1所示。
图1 业务部门架构图
其中，交互设计、视觉设计、页面制作和前端（JS）开发，都隶属于UED（用户体验设计）部门；后端开发、测试、网络运维，都隶属于技术部门。PMO、产品部、UED、技术部作为强矩阵式的架构，都由业务线的负责人直接管辖。项目运作上由项目管理部负责统筹管理执行。
随着项目管理工作逐渐规范化并得到各方的认可，W事业部也对项目管理部做了更新的职能定位。在此基础上，项目管理部在项目运作的摸索实践中，也帮助其他职能部门制定了相关工作守则。
举例来说，项目管理部职能范围有以下几部分。
负责全部项目的管理、执行和推进，保障项目安全，解决项目中的各种风险和问题，准时着陆正确的目的地。
建立并维护公司项目管理方法论，帮助公司项目追求最佳的项目管理实践。
建立并实施一系列通用的项目管理过程和模板，不断优化公司项目管理的过程，对项目管理人员予以指导。
建立并使用规范的流程、工具和术语，便于项目团队内部、团队之间以及各个职能部门的沟通，减少误解，提高项目沟通及协作机制的效率和效果。
对项目进行组合管理，通过向项目干系人和各职能部门提供项目管理的普及和培训，提高公司项目管理的核心能力。
建设并维护项目管理信息系统（如JIRA、Confluence等），提升项目管理在流程、运作规则和团队协作等方面的自动化水平、自适应水平。
加强项目管理体系建设，通过针对项目管理的培训和指导，加强项目管理人员的队伍建设，提高项目管理人员的管理水平和一线管理能力。
对项目、项目管理人员、项目各角色成员进行绩效管理。
期间，公司HR部门也多次邀请业界知名的项目管理专家，来公司做项目管理领域的系统培训。经过较长一段时间的运作，W事业部的项目管理水平有了较大提高，主要表现在：规范了项目中的协作流程，项目计划、进度节奏、执行管控等更加合理完善，项目管理的方法、工具得到广泛应用，沟通更顺畅，提高了管理效率和效果。
四个核心要素的体现
项目管理有四个核心要素即SPPT——Strategy战略目标、People优秀人才、Process制度流程、Tools管理工具。整个项目管理能力的改进过程中，都必须同时伴随着项目管理关注的这四个核心要素的配套支持。
这四个核心要素看似简单，但在互联网项目管理领域的从业者中，真正了解并实践的人并不多。举例来说，我之前面试过几十位应聘项目管理的候选人，几乎没几个人能正确回答出这四个核心要素的内容并用于实践指导。很多人都会把SPPT与项目管理过程的四个指标（多、快、好、省）以及项目管理的四个核心制约因素（范围、时间、质量、成本）互相混淆。
项目管理关注的这四个核心要素相辅相成，相互依赖，就像四个联动的齿轮，来确保项目的顺利实施，如图2所示。
图2 项目管理四个核心要素
以下就这四个要素，谈谈如何结合项目管理的具体实践。
Strategy战略目标
战略目标可以理解为做事的目的和意义，目的和意义不同，会导致做事的结果完全不同。所以项目开始前，项目发起人首先要让项目成员理解项目的目的和意义。
举例说，A公司W事业部负责微博业务的管理与运营，但因A公司的战略问题，导致微博业务起步很晚。2011年1月，A公司启动了微博宽屏版项目。同年4月，按计划设计开发完成进入测试阶段，但测试完成后，部门领导却宣布当前的项目不能上线。这让项目团队当时很有挫败感，也提出很多疑问和质疑，产生了较大的负面情绪。
分析项目不能上线的原因，是由于当时做出来的产品和立项之初的战略目标、产品愿景（舒适阅读、视觉盛宴、极速体验）有较大差异。也就是说实际做事的结果与立项之初的战略目标不匹配。在项目立项后，宽屏版的产品设计方案和交互设计方案盲目追随国外网站Twitter，缺少自主思考，对宽屏版中“宽”字的理解不到位，导致项目成员走了较大的弯路。后来又经过两个多月的不懈努力，对微博Timeline及相关页面进行一系列的改造优化，使得视觉层面全面转向宽屏版效果，并在用户体验、浏览速度等方面也进行了优化，为用户提供更加舒适、快捷的阅读体验。最后在项目启动5个月后终于正式上线。
项目成员辛苦按项目计划，花费将近三个月做出来的东西，结果未能得到上线发布的认可，无论摊到哪个团队身上，都会有各种疑问或负面情绪。这个例子说明项目执行之前，正确理解项目战略目标很重要，如果项目负责人或项目成员不能正确理解发起这个项目的意图，就很难把项目做好，也得不到想要的结果。
People优秀人才
在项目管理中，人的要素非常重要。有时在项目中只要有足够能干和优秀的人来担任项目负责人或核心骨干，哪怕是在制度和流程不完善的情况下，也能做出好的结果。
互联网公司最有价值的就是人。办公桌椅、电脑设备等都会折旧，但对一家互联网公司来说，始终在增值的就是公司的每一位员工。但同时互联网行业竞争激烈，人才流动量也很大。以技术开发岗位为例，同一层级技术开发岗位，招聘进来的开发工程师的水平都有所差别，因此其参与到项目时，对同一个开发任务点，所花费时间和产出效果可能也会因人而异。从整体项目的维度，如何将人的因素融合到合理的项目节奏，就需要与制度、流程相结合，以制度机制稳定人。
Process制度流程
项目管理在很多时候研究的是做事的方法次序和安排、流程和过程。建立并实施完善优质的制度流程，能让公司内部管理的效率和效果显著提升。
图1中的A公司W事业部划分了项目的各种角色，如何制定一个符合部门体制又能确保各职能部门高效协同工作的制度流程，并持续改进优化是项目管理需要重点关注的。当时结合具体业务实际，制定了如下流程，如图3所示。
图3 项目管理中的制度流程
立项之后，进行产品需求方案的设计、评审和讲解。
产品评审并讲解完后，项目团队可以做两事件：后端技术人员做后端技术概要设计和评审准备；交互设计师做UE设计、评审准备和后续的讲解。
UE评审并讲解完后，项目团队可以做三件事：前端技术人员做前端技术概要设计和评审准备；视觉设计师做UI设计和评审准备，有必要的话，需要再做UI讲解；测试工程师做测试用例的编写和评审准备。
UI效果设计完成并评审通过后，进行页面制作（切图）环节，将页面提供给开发人员做嵌套。前、后端概要设计完成并评审通过，开发人员拿到页面，进入开发阶段。测试用例编写完成并评审通过，同时也拿到了开发人员提供的测试版本，进入测试阶段。当测试基本完成后，在正式上线之前，给项目的核心干系人（主要是指各职能部门的领导）做产品演示，用来展示项目团队在项目执行期间的工作成果。产品演示环节，视项目规模大小情况而定，不是必须要有的环节。产品上线后，进行数据监测，并根据数据情况持续进行产品优化，逐渐满足立项之初战略目标的预期。
项目管理要在整个项目执行过程中做全程的管控，打通经脉、扫清障碍、风险预警和规避，帮助团队解决在项目执行过程中遇到的各种问题。
结合项目管理第二个要素People提到的人的因素，从整体项目的维度，为了将人的因素能契合到合理的项目节奏，在这个流程中设立了“后端概要设计评审”、“前端概要设计评审”两个环节，这两个技术层面的评审环节，可以针对部分技术水平参差不齐的开发同学，确保在开发质量和时间点上趋于理想预期的节奏。设立前、后端技术概要设计评审会的目的，是希望开发工程师在正式编码之前，对其所采用的技术选型、技术实现方案，能够由开发经验丰富的开发主管做把关和指导，采用最优的技术方案来实现，并评估出合理的开发周期。
从项目管理的角度来说，给新员工或者刚刚接触这个流程的开发工程师介绍这两个技术评审环节时，一定要注意沟通技巧，不能直接对开发工程师说“工程师技术水平参差不齐”之类的话，容易伤人自尊。项目管理要从整体产品复杂度的角度来表述，比如“微博产品的复杂度高，涉及面广，你开发的这个模块也许会引发其他模块的问题”、“需要做技术概要设计评审，由你的开发主管来把关……”这种表述。
总之，一个好的制度流程，能让项目团队持续产生好的项目结果。一个坏的制度流程，几乎无法让项目团队有好的成果。
Tools管理工具
项目管理中涉及项目的分解、执行的优先级，所以真正要把一个项目做好，很多时候要用到一系列工具、方法或技术。其中项目分解的要点是我们要掌握怎么把一个复杂的问题简单化、怎么排定各业务模块的优先级，找准时间管理、进度管理中的瓶颈，找准关键的人和路径等。这些内容可以落地到Office办公软件来管理，也可以落地到专业的管理工具来管理。如果项目数量少，落地到Excel可能会感觉比较轻松。但当项目逐渐增多，几十个、上百个项目并行执行出现时，如果再用Office去管理就力不从心了。这种情境下需要选择适合自身团队特点的专业管理工具来辅助项目管理。优质的项目管理工具，是项目成功运作的承载。
人，应该做自己喜欢并且擅长的事情。工具也一样，利用它最出色的特点。在提案跟踪及项目管理工具方面，我比较喜欢Atlassian公司的JIRA。项目执行管理 、敏捷开发管理、体系流程管理 、产品Bug跟踪、提案跟踪、需求管理、客户服务等，都是JIRA最擅长的。
简单总结一下项目管理关注的四个核心要素（SPPT）：Strategy，就是我们要了解做项目的目的和意义，它决定我们做项目的方式和方法；People、Process 、Tools就是我们需要从人、流程、次序和管理工具上去做了解和领悟。
如何做好研发团队管理
从组织架构上，一个团队可以是这样的构成：一个团队领导者+若干团队核心+团队普通成员。 早在第一篇文章“个人信念与团队信念”里，我就曾说过，团队领导者和团队核心是团队价值观的主要构建者和传播者，整个团队有没有核心价值观，主要是看这些人能不能形成一个稳定的核心价值观。而其实，我还没有明确说的一点就是，在团队领导者和团队核心这样的架构里，还同样隐含着“连长+政委”的模式。 所谓的“连长+政委”，并不是什么新鲜概念，它另一个更通俗易懂的名字叫：把支部建在连队上。 之前，我一直很好奇，为什么毛泽东在文革中犯了这么大错误，毁灭了这么多了中华优秀传统文化财产和这么多的知识及社会精英人才，而后人还这样崇拜他，特别是，中国改革开放中形成的第一代企业家，其中的很多人，都把毛泽东的治军、治党理论用于自己的公司管理，其中一个影响深远而又非常著名的概念，就是：把支部建在连队上。
“连长+政委”，其最原始的意义，是要加强组织对军队的绝对控制力，“连长”，可以理解为业务骨干;而“政委”，可以理解为思想工作者，用于协调团队内部关系，化解团队内部矛盾。“连长”，保证了这个团队在业务层面可以向前推进;而“政委”，则负责团队内部人员的协调、流程的组织。
我们总说“作团队”，“作团队”，其实，在我看来，在你自己可以充分作事正确作事的基础上，所谓的“作团队”，在人与人关系方面，需要额外考虑的无外乎两点：组织架构和流程安排。前者，是团队的静态存在形式;而后者，是团队的动态存在形式。不断优化这两个方面，就可以让我们的团队水平得到不断的提升。
说回文前，其实，你只要仔细研究一下国内几个大企业的组织架构，就很容易发现“连长+政委”这种组织形式的影子，比如：华为，海尔和曾经的巨人。但是，在我看来，体会最深的一点就是，我们没有必要在人事安排上非要弄出两个人来，一个负责业务，一个负责思想。如果要学习，就学习它最精髓的内容。 它最精髓的内容是什么?
说白了，就一句话：业务需要有人作，思想也需要有人作。 甚至，说得更通俗一点：黑脸需要有人唱，红脸也同样需要有人唱。 “业务+思想，黑脸+红脸”，可以让我们既兼顾到业务，又兼顾到“和谐”。
一个团队，其能存在和发展，最终，还是要靠业务作得好，靠业绩作得好。但是，如果唯业务论和唯业绩论，又很容易让整个团队进入一种非常偏执、压力非常大的状态，所以，我们不能一味的施以高压以获得唯一的业务增长，在追求业务增长的过程中，还需要考虑到团队成员个人的感受，个人的成长以及每个人自己的个性诉求。
如果我们把“作业务和关注团队成长”这所有的事情都寄托在唯一的团队领导者身上，显然是不太现实的，即使他是悟空，恐怕也是分身乏术。团队领导者，也是一个普通人，我们不能把团队成功的希望全部寄托在“团队领导者必须是全才”这样一个虚无缥缈的幻想之上。
所以，从这个层面来说，在所谓的团队协作中，作为团队核心，应该主动去承担一部分业务或者思想工作。
既然团队领导者，没时间去作思想工作，那我们就可以帮把手，多跟团队成员沟通和交流，帮大家多化解一些对团队和项目的困惑;
既然团队领导者，现在只有空钻研某一块的业务，那我们就可以尽己所能把其它需要钻研的业务主动承担起来。
当然，这样作的前提，首先是团队核心要与团队领导者充分交流、沟通，并达成一定的信任关系。 也就是说，在我看来，我们需要把握和关注的，是“业务和思想”这两样最本质的东西，而不是“连长和政委”这两个虚无的职位。我们人人都可以成为“连长”或“政委”，关键的前提是，你有没有意识到，需要在团队中主动承担一些角色，而这些角色并不是一定需要某个职位才能去作的，利用你的影响力，利用你掌握的专业技能，找准自己可以努力的方向，去帮团队作弥补。这也是我一直倡导的心态，在任何时候，以积极的心态把好的影响力带给团队，而不是相反，只会抱怨和苛责。
身处团队中的人，会经常发现团队有很多不足之处，很多人，习无为常形成的惯性就是：只知道抱怨这不好，那不好，却林不曾想过自己从哪些方面可以帮着团队作改善。我想说的是，如果你老是这样，你最终不是成为怨妇，就是被这个团队淘汰，团队需要的，不是将自己置身事外的抱怨和旁观者，你是团队一员，理所应当成为一个实践者，发现不足，就要从自己的角度想办法去改进，虽然不见得都有效果，但最起码会让你保持一种积极向上的心态。而这种心态，无论你将来到哪里作事，都会让你受益良多。
Agile敏捷管理
目录：
一、什么是Agile
二、什么样的团队适合Agile
三、敏捷开发的实施步骤（SCRUM）
四、Agile敏捷管理的具体实施
五、敏捷工作坊的体验
六、结语
七、附：SCRUM在教育和政府领域的应用
从本质上讲，敏捷（Agile）并不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代，让产品逐渐完善。
在数十年前，瀑布式项目管理是软件研发的主流方法，在研发过程中，团队成员将会花大把的时间和精力在项目前期去收集资源和信息，然后基于这些去做产品设想和研发规划。
到了70年代，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度还很慢，显然Out了。尤其到了90年代末期，开始出现黑客来捣乱，这就意味着前功尽弃、全部推倒重来，这简直是研发的噩梦。
相比瀑布基于线性、可预测性地去开发产品，研发人员更想要能够灵活管理用户反馈、Bug和需求的方法。这也就是敏捷方法出来以后受欢迎的原因。
另外，你也可以通过这个视频学习 什么是敏捷（Agile）
在2001年，17位研发人员共同探讨出了《敏捷宣言》这份文档，阐述了他们对于软件研发的看法。文中他们定义了敏捷开发需要遵守的四项价值观。
总结为：
尽管如此，这四项价值观并不意味着我们就该放弃工具、文档和计划。因为它们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注更核心的事物：人、产品模型、协作和迭代。为了让这四项原则变得简单易懂好执行，他们又将写了 敏捷开发12项原则 作为指导：
如果我们把这些原则和遇到的问题对号入座，很快我们就会发现，这12项原则正是对应了客户期望。比如，客户不会关心开发文档写的怎么样，他们更感兴趣交付的成品能干什么；他们不在意你的开发计划，他们希望你能立马交付；昨天他们想要修个BUG，而不是等到下次版本更新。
我们总会遇到需求多样化的客户，而这时，敏捷能够确保你在研发过程中始终将用户需求作为核心。
敏捷虽然听起来光鲜亮丽，但不是所有项目都能用敏捷来做。
敏捷在公司里投入使用后可能与预想的结果背道而驰。敏捷意味着快速推进项目，也就是说并不是所有事情都是按部就班。因此，我们得知道在这种快速变化的环境下，团队是否能够适应变化。
所以在部署使用敏捷前，需要团队先明确几个问题：
1.你是否会愿意接手目标不明确的项目？
敏捷项目管理中有句话叫做：快速失败。比如我们接手了一个连最终产出都不明确的项目，首先我们会先交付最小模型产品，这时我们得做好被质疑的准备。毕竟没人知道要做出怎么样的产品，所以我们的最小模型的产品很可能是个怪胎。在与客户反复测试后，我们才会逐步了解他们的真实需求，这时候我们离成功又近了一步。
2.你会如何规避项目风险？
就像我们前面提到的，敏捷提倡不断从犯错中积累学习并持续迭代。如果我们走老路，用传统项目管理的方法来推进的话，我们会要承担更大的风险。当然就算我们开始敏捷之后，也要准备好随时响应未知问题。
3.你的团队能有多灵活？
作为项目经理，我们的责任是和客户一起把产品做的更好。这么做很可能和设计、研发、其他成员的想法背道而驰。这时我们需要找主心骨聊一聊，是否愿意放下老套路，根据用户需求来调整想法、重新规划方向。
4.公司阶层制度严格吗？
敏捷的其中一项原则不仅是和用户一起工作，研发成员的身份也会发生变化。你们公司的文化开放吗？是否能接受扁平和开放的管理方法？
5.你怎么衡量进度？怎么定义成功？
用敏捷来管理项目能够帮我们逐渐进步的同时也督促我们将产品做得更好。如果因为突发灵感而放弃正在执行的任务，那么敏捷将毫无意义。我们先花些时间来看看团队是怎么看待进步和成功。然后再来看我们是不是离最终目标一步步的更近了？
在Scrum中，产品经理和项目团队紧密协作，一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。
有了产品清单，产品经理就会开始确定需求优先级，研发团队通常会在接下来30天左右的迭代中产出“潜在可交付版本”。当研发团队制定了迭代清单后，除了团队成员外，任何人都不能再加入需求。当一轮迭代完成后，全员再次分析需求清单、划分需求优先级，然后进入下一轮迭代。
1.三个角色
2.三种可视化文档
另外，用户故事要注意必须完整，遵循INVEST标准：
Independent——让一个用户故事独立于其他用户故事
Negotiable——可协商性，协商更多细节
Valuable——必须对客户具有价值
Estimable——开发团队需要衡量用户故事，以便确定优先级和工作量，并便于安排工作计划
Small——规模小，至少要确保在一个冲刺周期中能完成、
Teatable——可测试，便于确定它是可以完成的
3.三种不同形式的会议
1、确定敏捷开发中的3个角色：Product Owner, Scrum Master, Scrum Team。
2、拟定待办事项清单，并确定优先级
3、改进和评估待办事项清单：
·要完成这些事项，现有信息足够吗？
·是否细分到了可以评估的程度？
·是否成员都能接受，用于评定一个事项已完成的标准？
·用相对难度去评估，利用斐波那契数列的数字
4、冲刺规划会：Product Owner, Scrum Master, Scrum Team一起规划冲刺的内容，记录每个冲刺完成事项的点数
5、将工作透明化：利用白板和燃尽图更新进度
6、每日站会
7、冲刺评估和冲刺展示：将成果展现给产品负责人看，哪些事项可以移到“完成事项”一栏，并接受评价。
8、冲刺回顾会
9、上一个冲刺阶段结束之后，立刻开始新的冲刺阶段
在冲刺阶段结束之际，把所有已完成的用户故事列出来，将各项难度评分加在一起，最终的数字就告诉我们团队的进度是多少。然后再看未完成用户故事的难度分值总和，就可以知道什么时候可以完成项目。
速度 X 时间 =交付工作量
敏捷非常注重节奏，当你有多个任务要交付，团队更需要注重节奏的把握。而身为项目经理，我们的职责是让整个团队通过协作最终交付产品。
敏捷是不断规划、执行、学习和迭代的过程，敏捷项目通常可以分解为一下7步：
第1步：通过战略会议定义你的愿景
每当开始新项目时，第一件要做的事情是定义产品的业务需求，或者说想要达到的愿景。事实上，我们只需要回答一个问题：你为什么想要做这个产品。这是我们心中的蓝图，时时提醒我们不要跑偏。
作为一家产品公司，定义愿景的最佳方法之一是电梯演讲：
用于：（哪部分目标客户）
需求：（用户的需求）
类别：（我的产品是哪种类型）
功能：（产品的价值、客户为什么选我们）
竞品：（主要的竞争对手有哪些）
差异化：（和竞品的差异化描述）
即使我们做的不是软件产品，我们也可以根据项目的目标来调整上述内容。
战略会议的参与角色都有谁？
此时我们要让更多人认同这个项目，所以很多关键的利益相关者自然不能缺席，包括相关主管、经理、主任和产品经理。
战略会议该什么时候召开？
项目开始前我们就该来开战略会，或者至少每年一次的定期会议来保证愿景依然不过时
战略会议要召开多久？
这个就由你主观来决定了，一般来讲，花4-16小时来探讨战略已经足够了。
第2步：绘制产品路线图
当我们开完战略会后，就该轮到产品经理把愿景变成产品路线图。产品路线图能帮助我们纵观全局、理清思路，让我们有宽松的时间来开发每个产品需求。“宽松”并不是说我们可以花数天或是数周的时间来推进每步计划，而是轻量级的去定义产品、理清需求优先级和粗略估算产品每个需求的时间。
项目管理专家Roman Pichler认为：目标导向的产品线路图能够聚焦于目标和产出结果（比如：获客、增加活跃度、满足客户需求）。而产品特性来自于这些目标，所以我们在制定目标时应谨慎，每个目标对应3-5个产品特征。
而每个目标，我们需要包含5个关键信息：时间、名称、目标、产品特征和衡量标准，有了这些，我们就能清楚知道哪些该做、什么时候算做成功了以及我们如何取得了成功。
产品路线图由产品负责人画，同时听取利益相关者的想法，如客户、市场、研发代表等，并最好在战略会议结束后着手画产品路线图。
第3步：制定发布计划
当我们有了战略和计划，下一步我们就可以暂定几个时间节点。
这个阶段产品经理要严格按照计划发布新版本。我们也不用担心功能不齐全的问题，敏捷项目都会有多次发布的过程，所以我们只要优先发布核心功能的版本即可。
举例来说，你的项目要在11月交付，而你可能在2月初就已经做好了最小模型，打算在5月左右发布完整版。这些时间节点的安排都将由你的项目难度和每次迭代时长（或者说每次达成目标需要的工作时长）决定。通常每次发布新版本都需要经历3-5次迭代。
谁来制定发布计划？
产品经理、项目经理和所有团队成员都该来参与其中。当然，邀请少数利益相关者来加入其中也是对其他成员的鼓励，让团队能够尽早开始。
发布计划什么时候来做？
越早越好，你的发布计划应该在确认新产品后的第一天开始制定。在随后的每个季度中至少记录一次。
制定发布计划要多久？
一般来说会需要4-8小时，实际时长由具体情况决定，但不能因为它拖进度。
第4步：制定迭代（Sprint）计划
迭代（Sprints），我将其理解为通过短期研发完成具体任务来达到目标的一个过程，也是帮助产品经理和研发团队逐渐切入项目细节的方法。
通常情况下，每次迭代大约要花费1-4周。具体的时长我们需要根据团队过往的表现情况来制定，同时尽量保持每次迭代的时长相同。
哪些角色参与制定迭代计划？
迭代是整个团队的活，因此，产品经理、项目经理以及其他所有成员都该积极参与其中，表达自己的声音和想法。
迭代计划什么时候来制定？
在每次迭代周期开始前，我们就需要做好迭代计划。比如说，你的计划是每周迭代，那么就你就需要在每周一（或者你选好的某一天）告诉其他人迭代计划。
制定迭代计划要多久？
迭代计划是迭代周期的基石，虽然如此，我们也不要在这上面浪费过多的时间，通常2-4小时足够了。写好了迭代计划也就意味着我们已经踏上了正轨。
第5步：每日站会
在每次迭代过程中我们需要有时间来确认项目组没有遇到阻碍，同时保证能准时完成既定目标。这时候我们就需要使用每日站会。
每日站会，如同字面意思一样通俗易懂，每天花15分钟左右的时间来讨论下面3件事：
昨天我完成了哪些事情
今天我打算做哪些事情
我有遇到哪些问题，如何解决
或许讨论这3件事，可能让团队的一部分人的脸挂不住。但这对推动敏捷项目管理的沟通有积极意义。敏捷之所以能够跨团队协作，主要依靠的就是团队快速响应和有让成员发声表达的空间。
第6步：迭代（Sprint）结束了？那就进入评审阶段吧
如果迭代中一切顺利，那么迭代周期结束后，我们需要来检测下软件的功能。我们可以借评审的机会来向团队成员和利益相关者展示成果。
作为产品经理，你对产品功能有选择的权利。如果有哪步错误，尝试多问几个为什么？下次迭代时我该怎么调整才能让团队达成目标？敏捷是不断学习和迭代的过程，你的流程管控和最终产出也是同一道理。
哪些角色参与评审？
团队全员和利益相关者都应该参加迭代评审会来确认项目进度和表达他们的观点。
什么时候执行评审？
每次迭代结束后就可以开始。
评审阶段要多长久？
无需特意去准备PPT、功能说明，审查会最多1-2小时就够了。
第7步：迭代（Sprint）回顾总结
为了让敏捷项目管理能顺利运作，我们在每个阶段结束后需要知道下一步要做什么。这是我们在迭代回顾阶段要做的事。当迭代和审查结束后，接下来该去决定下次要做哪些工作。我们需要回顾下，在迭代中是否发生了些事情改变了你的既定时间，甚至是项目愿景。
谁来参加回顾总结会议？
回顾总结是审查的延伸，这时利益相关者离开也没有关系，而其他团队成员则加入其中，给出自己的意见。
什么时候来做？
当然最好是在审查阶段结束后，立刻开始迭代回顾总结。
这会花多长时间来做？
概括下来大概几个词：简短明了、甜蜜温馨，最多花1-2小时来总结和大致规划下次计划。
工作坊的体验主要是让学员大概体会一下运用敏捷的方式开发项目的流程，并通过一些敏捷工具深化在敏捷开发过程中的运用。
1、制作自行车项目
（1）分组并确定团队内敏捷3个角色
（2）定冲刺周期（每10min1个sprint，3个sprint）
（3）在冲刺开始前，给每个组15分钟开战略规划会，此期间验收人对自行车提出需求，要满足什么样的功能，团队开战略会列出任务清单。
（4）每个sprint结束后给每个组7分钟开站会
（5）每个组的SCRUM Master更新看板和燃尽图
（6）进行项目验收，对成果进行点评
（7）结束后小组内进行总结回顾会
2、乐高堆房子项目
（1）分组并确定团队内敏捷3个角色
（2）定冲刺周期（每15min1个sprint，4个sprint）
（3）在冲刺开始前，给每个组15分钟开战略规划会，此期间验收人对自行车提出需求，要满足什么样的功能，团队开战略会列出任务清单。
（4）每个sprint结束后给每个组10分钟开站会
（5）SCRUM Master更新看板和燃尽图
（6）在第三个Sprint开始时，要求团队内交换2名成员到其他组完成自己组的任务，期间不得交流，只能依据看板进行
（7）进行项目验收，对成果进行点评
（8）结束后小组内进行总结回顾会
七、SCRUM的应用
1、SCRUM与教育
教师首先让学生对自己的性格做评价，将自己划分为不同类别，分为”勇敢类“，“喜欢数学类”，”关心他人感受类“，”勇往直前实现目标类“，将不同类型的学生组合在一起，形成多功能小组。教师拟好所有待学事项，让各小组的学生每天将“所有事项”移到“待办事项”中，然后开始动手，打开教材，自己学习，组内互教互学。教师从“完成事项”一栏随机挑出一些事项问组内成员，以确定每个人都理解相关概念，只有当每个人都理解了之后，才符合所说的”完成的定义“，一切交给学生来做决定。
2、SCRUM与政府
制定政策：每周都去改变一件事情，采用增量方法，每周都会展示一种可交付的产品，每个机构都会切实感受到成果的存在。
书籍建议：
《敏捷革命：提升个人创造力与企业效率的全新协作模式》
SCRUM的一些工具：
Leangoo（领歌）——基于看板的可视化协作
Confluence——Jira
国外有Redmine，Axosoft，国内有禅道，一些自研工具（百度Icafe，阿里Aone，腾讯Tapd)
劳伦斯在《七根智慧之柱》中写道：所有人都做梦，但是却不尽相同，那些夜里在蒙灰的心灵角落做梦的人，早上醒来往往发现是空洞虚无的。而那些白日做梦的人，则是最危险的，因为他们会在睁着眼睛做梦的时候，把梦想变成现实。
看了这么多，不如试一试吧！此文由个人整理而来，主要来源于个人在敏捷团队时敏捷开发的逻辑和思考，以及明道云博客和敏捷相关书籍、英文文档翻译等。如有疑问或补充，欢迎评论下方交流~