阿尔伯塔软件项目管理-I-笔记-全-
阿尔伯塔软件项目管理 I 笔记（全）
001：专项课程预告 🎬
在本节中，我们将简要介绍艾伯塔大学软件产品管理专项课程的整体框架与学习目标。
我是乔纳森·舍费尔，一名计算机科学家，现任艾伯塔大学理学院院长。
我很荣幸向您介绍由我校计算机科学系开发的软件产品管理专项课程。
这套系列课程将教会您如何成功地将一个软件产品从构思引导至交付。
艾伯塔大学被公认为世界领先的公立研究型与教学密集型大学之一。
作为加拿大顶尖大学之一，我们在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。
我们的热情在于为学生成功提供起点。
我们的目标是激励、转变和提升我们的学生，并帮助他们实现目标。
强大的协作与沟通技能，对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。
考虑到这一点，我们的计算专家团队将为您提供掌握敏捷软件开发所需的过程与实践。
我们对软件产品管理流程的实践经验，将为您提供直面挑战所需的一切。
我们将教您如何理解并优化客户的软件需求，以及如何将这些需求传达给开发团队。
您将学习从监控项目到确保其符合客户需求、遵循项目计划并达到预期质量水平的技术。
您将有机会加入一个软件产品管理社区，在那里您可以分享经验并从他人的见解中学习。
最后一门课程是一个为期六周的毕业项目，它将为您提供在真实模拟中应用这些管理技术的机会。
成功完成毕业项目后，您将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。
很高兴您对我们的专项课程感兴趣。我们已经尽力使其成为一次有价值的教育体验。
现在轮到您了。祝您好运。
在本节课中，我们一起了解了艾伯塔大学软件产品管理专项课程的概览、目标以及它如何帮助您为成功的职业生涯做好准备。
002：《软件产品管理简介》 🚀
在本课程中，我们将学习软件产品管理的基础知识。这是软件产品管理专项课程的第一门课，也是最短的一门。通过前两周的学习，我们将了解软件产品经理的角色、聆听行业专家的访谈、理解敏捷软件开发的核心，并对整个专项课程的内容有一个初步的认识。
课程概述与目标 🎯
本节将介绍本课程的基本信息和学习目标。
欢迎来到软件产品管理简介课程。
这是软件产品管理专项课程中的第一门课，也是课时最短的一门。
在前两周，我们将完成以下目标：描述软件产品经理的角色；展示对软件产品经理及其行业同事的访谈；解释敏捷软件开发的核心内容；并让你对专项课程后续涵盖的主题有一个整体了解。
在本入门课程结束时，你将能判断这个专项课程是否符合你的个人学习目标。
课程内容与受众定位 📖
上一节我们介绍了课程目标，本节中我们来看看课程的具体内容和适合的学习者。
如果你的背景是软件开发，你可能会觉得本入门课程中介绍的技术信息比较基础。
但对于软件领域之外的学习者，本课程将提供一些关键术语和概念，这些将是学习后续专项课程的基础。
如果你在学习本课程后感到意犹未尽，请继续学习我们专项课程中的下一门课。
核心技能：积极倾听与学习 💡
一个高效的软件产品经理需要具备核心技能。以下是关于这项技能的阐述。
一名高效的软件产品经理善于倾听，能够从可能无法完全表达或理解自身需求的用户那里，构想出有价值的产品。
善于倾听就像积极学习一样，当你对学习持开放态度时，即使只学到一件新事物，也可能极大地改变你对世界的理解。
我们希望你在深入钻研软件产品管理专项课程时能学到许多东西。
我们期待在论坛中听到你的观点。
总结 📝
本节课中我们一起学习了《软件产品管理简介》课程的基本框架和目标。我们明确了软件产品经理的角色描述、访谈学习、敏捷开发介绍是前三周的重点。课程兼顾了有技术背景和无技术背景的学习者，并强调了积极倾听与持续学习是产品经理的核心能力。我们鼓励你学完本课后，继续参与专项课程的后续学习与论坛讨论。
003：更好的软件
在本节课中，我们将要学习软件产品管理的基础概念，特别是如何从多个视角来理解和实现“更好的软件”。我们将探讨产品经理的角色、开发团队的构成，以及确保项目成功的三个核心视角。
大家好，欢迎来到Coursera的软件产品管理专项课程。我是Ken Wong，阿尔伯塔大学计算机科学系的副教授，我的专业领域是软件工程。
在本专项课程中，我的目标是让你成为一名自信且合格的软件产品经理。如果你已经是一名软件产品管理专家，那么我的目标是让你在这个领域变得更加出色。
回顾你过去参与过的软件项目，你是否思考过它是否成功？项目是否可以做得更好？我相信大多数人的答案是肯定的。本专项课程将向你展示如何与客户合作，并组织开发团队来打造更好的软件产品。
既然你已经知道项目可以做得更好，那么请花点时间思考一下，作为一名软件产品经理，你希望提升自己的哪些方面。当然，你可能需要精进许多技术技能，比如特定的平台、语言和工具。但除此之外，还有更多内容。让我们一起来探索。
前面提到，你将与一个开发团队合作。在整个专项课程中，我们会多次讨论这个话题。
请选择你认为通常构成软件开发团队的成员（可多选）：
A. 程序员、编码员或开发者
B. 客户
C. 用户界面专家和图形设计师
D. 质量保证专家或测试员
你将合作的每个开发团队都是独特且不同的。通常，一个开发团队由编码主力、创意设计师和测试人员组成。因此，最正确的答案是A、C和D。尽管你和你的开发团队会与客户紧密合作，但客户通常不被视为开发团队的一部分，所以排除答案B。
如今，打造出色的软件产品需要许多拥有不同技能的人持续协作。但他们应该如何组织？团队可以遵循哪些实践来让工作更有章可循，减少随意性？我们开始进入软件产品经理的领域了。
让我们思考一些其他你可能会感兴趣的问题。我们的目标不仅是更努力地工作，而且要更聪明地工作。这其中涉及各种问题：当需要协调许多团队成员时，当需要开发大量功能时，当项目预计持续数年时，我们该如何管理这一切？
同时，我们不能忘记我们真正要解决的问题是什么。即，客户在软件产品中真正想要什么？他们对质量有何期望？我们可以建立哪些流程和实践来确保这一点？
统筹这一切可能相当棘手，尤其是在资源有限的情况下。我们如何在时间有限时处理范围？我们如何应对变更或避免项目范围失控？对客户而言，他们的需求可能不确定并会随时间变化。对开发者而言，工作量可能随时间波动，不同开发者之间的生产力可能存在巨大差异，我们如何适应这种变化？这些问题始终萦绕在软件产品经理的脑海中。
在本专项课程中，我将教你有效的管理技术来处理这类问题。这些技术将帮助你协助团队生产出更好的软件。特别是，你将学习敏捷软件开发。
打造优秀产品的关键因素是参与其中的人和流程。你将听到更多关于敏捷实践与规划、需求、评审和回顾等主题。
作为开始，本介绍课包含两个模块。第一个模块强调了软件产品管理的重要性和角色，并概述了整个专项课程的目标、结构和期望。第二个模块则介绍了随着你深入专项课程，各门课程将涵盖的主题。
现在，想象你自己是一名出色的软件产品经理。你有一个靠窗的好位置。请选择你认为与此职位相关的工作任务：
A. 与客户互动
B. 管理和跟踪开发进度
C. 与开发团队协作
D. 在客户和开发团队之间传递信息
E. 确保产品质量
作为一名软件产品经理，你将与许多不同的人互动，包括客户和开发团队。你的任务还包括管理和跟踪开发进度。确保产品按预期工作，并验证产品满足客户需求也是你的职责。
然而，作为项目经理，你不需要充当客户和开发团队之间的信使；你应该鼓励他们直接、频繁地沟通。因此，正确答案是A、B、C和E。
好的，让我们开始讨论如何打造更好的软件。软件产品经理需要理解多个视角来实现更好的软件。
第一个视角旨在为客户提供正确的软件产品。“正确的产品”意味着什么？这可能意味着许多方面的结合：它满足客户需求、易于学习和使用、不浪费他们的时间，或许看起来也很美观。基本上，客户对它感到满意。如果属实，我们说软件项目得到了验证。
在本专项课程中，你将学习如何理解用户、如何获取他们的需求以及如何表达软件需求。
第二个视角旨在将软件产品做对。但“做对”意味着什么？这意味着软件符合特定设计，而该设计又满足了一组既定的需求。如果属实，我们说软件项目得到了确认。
开发者可以进行评审和测试，以确保需求、设计和实现保持一致。此类活动旨在尽早发现缺陷，提高质量。他们希望避免客户在发布的产品中看到任何缺陷。在本专项课程中，你将学习改进软件质量的流程。
第三个视角旨在将产品项目管理对。但“管理对”意味着什么？这意味着确保上述其他视角得到满足。其核心思想是采用恰当的流程和文明实践来组织所有相关人员的工作。如果属实，我们说软件项目得到了管理。
此类活动促进了沟通和反馈，使每个人都清楚下一步该做什么。在本专项课程中，你将学习敏捷实践、估算与规划以及监控。软件产品经理需要在这些活动中扮演核心角色。
总结一下，我刚刚解释了实现更好软件的三个视角：正确的产品、做对和管理对。随着你深入学习本专项课程，你将更有信心了解并运用这些技术来创建更好的软件项目。这些技术包括促进沟通与反馈的流程，以更好地理解客户需求并组织开发团队的工作。
接下来，让我们谈谈软件产品管理的重要性。
本节课中，我们一起学习了软件产品经理的角色、开发团队的典型构成，以及实现“更好的软件”所必需的三个核心视角：提供正确的产品、将产品做对、将项目管理对。理解这些基础概念是成为有效产品管理者的第一步。
004：为何需要软件产品管理 🎯
在本节中，我们将通过一个故事来探讨为什么软件产品管理至关重要。这个故事将展示，如果没有有效的管理，一个软件项目会如何走向失败。
为了更好地理解为何需要软件产品管理，让我们从一个关于软件产品管理如何可能彻底失败的故事开始。
一个失控的项目故事
你刚刚担任了软件产品经理的角色，带领自己的软件开发团队，为一位新客户构建产品。
你的客户设想了一个革命性的新软件系统，每天能连接数十万终端用户。
项目截止日期定在六个月后。你非常兴奋，这是一个展示你能力的大好机会。你组建了团队，合同已签署，一切已启动。接下来呢？
为了掌控局面，你认为最好的做法是明确规划客户的需求。因此，你安排了一次会议，与客户面对面坐下，询问他们希望最终产品包含什么。
客户快速给出了一份非常有趣的想法清单，然后你就离开了。
你的开发人员热烈讨论着他们将如何解决这个问题。他们各自选择了一些功能进行开发，然后每个人都去忙自己的事情了。项目似乎有了一个非常高效的开端。
时间快进三个月。
客户发邮件给你，要求亲自会面，演示迄今为止的成果。突然间，你意识到，他们其实并不清楚项目的实际进展。
你向开发团队询问更新，他们兴奋地告诉你正在做什么，并保证他们的部分会按时完成。你告诉他们，客户想要一个演示。这时，气氛变成了恐慌。
他们说：“我们还没有集成任何功能呢。😊 我至少需要一周时间才能完成我代码中的这部分。我不知道有演示安排。”
现在，你也开始恐慌，因为你必须告诉客户你没有任何可以演示的东西。你的客户肯定会理解的，毕竟软件开发更像一门艺术，而不是一门科学。
一半的项目资源已经耗尽，事情似乎进展缓慢，你几乎看不清下周能完成什么，更不用说在演示截止日期到来时能为客户提供什么了。
又两个月飞逝而过。你现在距离交付截止日期只有四周了。团队完全处于恐慌模式。你的一位开发人员已经两周没来上班了，他们的代码成了整个系统的瓶颈。
你试图指派另一名团队成员来处理，但他们几乎看不懂原始的代码工作，认为不会有任何有意义的进展。现在，你正在弥补一开始就从未有过的时间。距离产品的首次演示还有两周，你的团队承受着巨大的压力。
每个人都在通宵工作，编写和测试代码。为了节省时间，你把所有最佳编码实践都抛到了窗外，并且希望客户不会发现那几个你实在负担不起人力去修复的漏洞。
截止日期正在迅速逼近。你别无选择，只能请求客户延长一些时间。我想他们不会高兴的。
但他们除了同意，还有其他选择吗？你为自己争取到了一些额外时间。然而，他们仍然想看看你目前的成果。两周后，演示日到了。
在模糊的视线和咖啡因刺激的打字声中，你的团队拼凑出了一个粗糙的产品演示。每个人都很紧张，他们唯一的安慰是想着项目很快就要结束了。直到客户开始彻底批评这个演示。
客户说：“我从来没要过这个。😊 这个功能的目的是什么？为什么决定把这个元素放在这里？我不能把这个展示给我的客户看。” 这令人心碎。
他们的要求将带来更多的工作量。为什么他们一开始不能更具体些？产品已经够晚了。你真的能再撑四个月吗？你真的能再撑四个月吗？
现在，你没能和家人一起享受计划已久的假期，而是被困在办公室里，把头撞在键盘上，希望有更好的方法。
引入解决方案：软件产品管理
上一节我们看到了一个缺乏管理的项目如何陷入混乱。本节中，我们来看看如何通过系统化的管理来避免这些问题。
阿尔伯塔大学可以提供帮助。大约只需一门大学课程的费用，你就可以按需访问整个计算机科学专业课程。
欢迎来到软件产品管理专业课程，欢迎来到更好的软件世界。
在本专业课程中，我们的专家讲师团队将引导你完成所有步骤，释放你内心的项目管理“忍者”潜能。
你将学习如何从一开始就掌控你的项目，这样，像忍者一样，没有任何事情会悄悄接近你。你将学习如何高效、协作地管理项目，这样，像忍者一样，团队中的每个人都知道正在发生什么。你还将了解行业当前的最佳实践，这样，像忍者一样，你将成为自己技艺的大师。
软件产品管理的核心价值
以下是软件产品管理在现代商业环境中的核心价值：
- 业务依赖软件：当今商业运行在软件之上。每家公司都有用于控制日常运营的内部应用程序，越来越多的公司通过网站和移动应用与外部客户建立联系。😊
- 需要专业管理：为了成功实现业务目标，公司需要能干的软件项目管理专业人员，他们能够交付在21世纪运营所必需的数字资产。
欢迎来到软件产品管理。这可能是一段激动人心的旅程，我们希望你能在此过程中学到很多。我们非常期待你的加入。😊
本节总结
在本节课中，我们一起学习了软件产品管理的重要性。我们通过一个生动的故事，看到了缺乏有效管理会导致项目延期、预算超支、团队士气低落以及最终产品不符合客户期望。相反，系统化的软件产品管理能够帮助我们从项目伊始就明确目标、协调团队、控制进度并确保交付价值，从而在当今这个由软件驱动的商业世界中取得成功。
005：1.1.3 软件产品经理的角色 🎯
在本节课中，我们将要学习软件产品经理这一核心角色的具体职责、所需技能以及其重要性。上一节我们介绍了软件产品管理的重要性，本节中我们来看看软件产品经理具体做什么。
软件产品经理是一个核心的管理角色。这个角色类似于电影制片人和导演的结合，但没有红毯上的名气。你负责软件产品的成功。
但这个角色远不止是管理一个项目。这个角色需要真正理解产品。这意味着你必须像真实用户一样，知道产品能做什么以及它独特的优势。
你还必须了解商业案例。商业案例指的是该产品能为客户带来的价值，以及该软件将如何改变客户的业务模式。
优秀的软件产品经理精通多个领域。他们能用客户和开发人员各自的术语与他们交流。他们能倾听并构想客户的愿景，与开发团队成员有效沟通，并激励团队取得最佳成果。他们还能管理客户的期望。
他们也知道如何让开发团队发挥出最佳水平。他们关心团队成员。这听起来像是你擅长的事情吗？
产品的成功也依赖于稳固的团队合作。程序员、测试员、用户体验设计师、图形艺术家必须协同工作。你的角色是赋能他们，让他们为你的项目贡献最佳努力。
软件产品管理是一个领导角色。让我们通过几个访谈，看看行业内的从业者对这个角色的看法。
“我的角色实际上是领导软件开发团队之一。不过，我确实将自己视为产品领导者，并且鼓励团队中的每个人都视自己为产品领导者。我的团队中有一位软件产品经理，我们紧密合作。产品经理负责向我提出需求，并帮助我理解客户需要什么，然后我则与团队一起努力满足这些需求。”
“我做的很多工作是定义产品愿景、产品战略、产品路线图，以及为开发团队和我们的体验设计团队制定规范。”
“让我兴奋、挑战我的是……让工程师、测试团队、文档团队明确无误地理解我们试图解决的问题是什么，这让我感到满足。”
“产品经理与客户会面，他们获得一个想法，一个关于某物可以如何的愿景。他们向工程团队及相关利益相关者清晰地阐述这个愿景，然后他们看到它被实现为可工作的软件。看到它最终交付，并看到它对客户及其现实产生的影响，这对产品经理来说是极大的满足。”
“看到客户对成品的反应，阅读相关评论，看到它在商店里销售，这是非常有回报的。”
“让团队围绕问题团结起来。如果人们来上班只是把它当作一份工作，他们不会创新。他们会做你告诉他们的事，然后回家。如果他们内化了你要解决的问题的使命……奇迹就会发生。”
“模糊性是一个巨大的挑战。我们发现客户并不总是有能力解释他们到底想要什么。因此，我们倾向于采用许多不同的策略来发现他们想要什么，即使他们无法告诉我们。我们可能会观察客户，可能会坐下来看他们工作一段时间，以帮助他们克服言语上的模糊性，找出他们实际需要什么。”
“人们可能有10种不同的解决方式。所以对我来说，实验和快速迭代的方法确实是解决这个问题的关键。这意味着承认意见分歧和缺乏共同愿景，然后说，好吧，我们到底要做什么来解决它，以及我们如何确定这是否是正确的行动方案。”
“作为一名领导者，首先，你需要能够做三件事。你需要能够用你的愿景激励他人，你需要能够组织需要完成的工作，你需要能够创新。”
“坦率地说，如果你自己不能创新，你的工作就是雇佣能帮助你创新的人。他们需要能够……倾听某人（客户）在说什么，并将其转化为需求，最终转化为工程团队可以构建和交付的规范。接下来，你需要能够沟通。”
“作为一个沟通者，你需要能够在组织的各个层面——向高管、工程团队、销售团队、营销团队——推销你的愿景。你需要能够理解所有这些事物存在于什么‘高度’，以及什么信息能引起他们的共鸣。建立真正良好关系的能力。”
“进行战略性思考，同时在需要时也要非常务实。这不是关于你。”
“作为产品领导者，这从来不是关于你，而是关于客户的问题。你的工作，我的工作，是爱上客户的问题。”
“人们要么从业务方面起步，然后意识到他们对软件有一些兴趣和技能，并且大致了解软件是如何构建的。然后他们会获得更多技术能力，并开始从那一侧参与进来。就我个人而言，我来自计算机背景，我从小就是一名程序员，慢慢地我转入了产品领导角色。但我也见过音乐专业的人成为了出色的产品领导者。”
“我们共同拥有的东西——我拥有计算机科学学位，而那个人拥有音乐学位——首先是领导力。如果你能激励人，能组织人，并且能创新，你就能在产品管理方面做得很好。”
“我认为其他人是从工程方面进入这个领域的，他们是一名优秀的工程师，但也许他们决定自己对愿景、规划方面以及协作方面更有热情，而不是实现方面。”
“我认为很多产品经理是在工作中学习的。归根结底……申请它。在线寻找，申请它，但要明白这一点：我们在这里是领导人的。你在这里是领导一个流程。你在这里是解决客户问题的。如果你从自我认知的角度相信那就是你……申请它。”
“他们应该了解他们的工程师。他们应该与工程师面临的问题、工程师能带来的机会保持高度一致。并且要真正、真正专注于这种伙伴关系。我认为客户和客户研究至关重要。这就像是产品经理的基本技能。所以这是基本要求。但我认为除此之外，还要真正擅长与自己的团队以及利益相关者团队建立伙伴关系。”
“对我来说，就是要痴迷于客户。立足于客户，真正深入地理解他们，因为你的工作就是代表他们。如果你从这一点开始，并且能做得很好，如果你能深入理解你的客户，那么你已经在某种程度上领先了。”
正如你刚才所见，软件产品经理的职位可以是一条充实的职业道路。优秀的产品经理赢得客户和团队成员的尊重。拥有成功产品交付记录的产品经理备受追捧。
无论你是想从开发者转向产品经理，还是你理解业务方面并想转向一个更亲力亲为的软件塑造角色，或者也许你想寻求职业转变，更多地从事软件产品管理工作。
无论你开始这条道路的原因是什么，本专业课程将逐步指导你成为一名有能力、有信心的软件产品经理。
那么，你还等什么呢？请查看下一课，了解本专业课程的概述。😊
006：如何成为更高效的学习者 🧠
在本节课程中，我们将探讨一些能够帮助你在本专项课程中取得成功的具体方法。我们将介绍几种经过验证的、能够提升学习效果的习惯和策略。
上一节我们介绍了课程的整体结构，本节中我们来看看如何优化你的学习过程，以最大化学习成果。
我们希望为你提供一些在本课程中取得成功的建议。
以下是在我们的专项课程中已被证明能带来成功的、成为更好学习者的方法。
- 采用适合你的学习方法。
- 积极提问。
- 提交自己的作业。
- 保持尊重。
- 保护个人数据。
首先，我们建议你采用适合自己风格的学习方法。
我们为你提供了视频讲座和配套的课程笔记。两者共同提供了课程的完整视图，因此你可以选择对你最有效的方法。
- 如果你通过阅读材料学习效果更好，那么请使用我们的课程笔记。
- 如果你更偏向视觉或听觉学习，那么使用视频讲座可能会让你更成功。
视频讲座也配有字幕和文字稿可供阅读。因此，结合使用课程笔记和视频讲座或许对你效果最佳。
接下来，我们建议你积极提问。如果你对课程材料不确定，很可能其他人也有同样疑问。请将你的问题发布在论坛中。我们这里有一个强大的社区，其他学习者和课程助教都会非常乐意帮助你。
我们的第三条建议是提交自己的作业。我们的评估旨在帮助你练习课程中涉及的许多概念。然而，如果你不亲自完成作业，就无法获得评估所能提供的全部益处。你不仅错过了学习机会，而且抄袭他人的作业可能会导致负面后果。
根据Coursera荣誉准则，抄袭是指你在未给予适当署名的情况下，复制他人来源的文字、观点或任何其他材料。应通过正确的引用来给予署名。抄袭在学术环境中是不可接受的，并且严重违反了Coursera的荣誉准则。抄袭可能导致作业不及格、被移出课程，甚至被逐出Coursera社区。
接下来，我们鼓励你在课程中保持尊重。这是一个为来自世界各地众多学习者提供的学习环境。请尊重你的同学，并记住他们可能来自不同的文化、说不同的语言、背景与你不同。你也需要注意自己书写的语气。在书面文字中正确解读语气并不总是容易的，因此某些内容可能会被误解或曲解。任何煽动性言论都将不被容忍。
最后，为了成为更好的学习者，我们建议你保护个人数据。我们鼓励你与课程中的其他学习者建立联系，但建议你不要在讨论论坛中分享你的个人住址、电话号码或电子邮件地址。
本节课中我们一起学习了成为更高效学习者的五个核心要点：选择适合自己的学习方式、利用社区积极提问、独立完成作业以巩固知识、在交流中保持尊重与理解、以及时刻注意保护个人隐私与数据安全。遵循这些建议将帮助你在本课程及未来的学习中取得更好的成果。
007：学术诚信与剽窃 🚫
在本节中，我们将学习学术诚信的核心概念，特别是剽窃的定义、表现形式及其严重后果。理解并遵守这些规则对于在学术和职业生涯中取得成功至关重要。
剽窃，根据课程荣誉守则的定义，是指在未注明出处的情况下，复制他人文字、观点或任何其他材料的行为。
剽窃在任何学术环境中都是不可接受的，是严重违反课程荣誉守则的行为。剽窃可能导致作业不及格、被取消课程资格，甚至被逐出课程学习社区。
那么，剽窃具体有哪些表现形式？什么行为会被视为剽窃呢？以下是几种常见情况：
1. 直接复制粘贴他人文字
如果你复制粘贴了他人撰写的文字，这将被视为剽窃，除非你正确地注明了出处。即使你改变了语序或替换了某些词语，你仍然必须为其原创工作署名。例如，在作业、测验或讨论区中复制粘贴其他学员或工作人员的答案，并将其作为自己的成果提交，这是被禁止的。
2. 提交他人创作的文件
在本专项课程的某些课程中，你可能会被要求提交图片或图表作为作业。提交由其他学员创作或提交的图片，并将其作为自己的作品，被视为剽窃，同样是被禁止的。
3. 窃取创意观点
某些作业可能需要一些创造性。窃取他人的创意观点，即使提交的文件是由你自己创建的，也被视为剽窃。在学术或商业环境中，两个人或更多人可能产生相同的想法。为了保护自己不被指控剽窃（不仅在本课程中，在你的职业生涯中也是如此），记录你的修改过程或以某种方式记录你的思考过程是一个好习惯。你可以考虑维护一个日志，记录每个想法或概念的起源时间。
请确保在整个专项课程的学习中，你提交的都是自己的原创工作。如果你在课程中发现剽窃行为，请标记该作业并提请课程工作人员注意。
在本节中，我们一起学习了剽窃的明确定义、几种具体表现形式及其带来的严重后果。遵守学术诚信是参与所有学习活动的基础，也是未来职业发展的必备素养。
008：专项课程概述 🧭
在本节中，我们将详细介绍软件产品管理专项课程的整体结构与学习路径。你将了解课程的组成部分、学习顺序以及如何充分利用本课程资源。
软件产品管理专项课程的结构如下。
专项课程共包含六门课程，从你正在观看的这门导论课程开始，并以一个顶点课程结束。
这门导论课程包含两个模块。你已经完成了第一个模块的大部分内容，该模块介绍了我们为什么需要软件产品管理。在下一个模块中，摩根·布拉德利将更详细地讨论软件产品经理必须具备的具体技能，并阐述这些技能对于该职业的必要性。
完成本课程后，你将可以继续学习接下来的四门课程。这四门课程的结构与本课程略有不同。在这些课程中，你将首先从宏观角度了解概念，然后深入探讨使软件产品经理成为任何开发团队宝贵资产的技能与实践。
这四门课程中的每一门都比本课程内容更多，每门课程包含四个模块。每个模块结束时都有一个课程考试，该考试成绩将计入你的专项课程总成绩。
我们设计此专项课程的方式是，每门课程都建立在上一门课程所获知识的基础上。
因此，我们鼓励你从头开始，按顺序完成所有课程。然而，我们的“软件流程与敏捷实践”课程和“客户需求与软件需求”课程经过特别设计，你可以按任意顺序学习它们。
鉴于我们来自一所加拿大大学，我想与你分享我们文化遗产的一部分。
你可能会认出这张图片是2010年温哥华冬奥会上的因纽特石堆。因纽特石堆是北极地区因纽特人用来标记路径的、类似人形的石制地标。
因纽特石堆的传统寓意是：“你走在正确的道路上。”
这不仅是你在本课程即将开始的旅程的绝佳隐喻，也代表了我们构建专项课程的方式。
我们希望你将专项课程想象成一个因纽特石堆。
这门导论课程就像是建造我们结构的地基。
组织软件生产活动很重要，弄清楚客户需求也至关重要。
因此，我们的“软件流程”和“软件需求”课程就像是这个结构的石腿。它们将支撑起其他所有部分。
除此之外，项目需要适应性规划工作和定期审查进度。因此，我们结构的下一个部分将是躯干和手臂，即“软件规划”和“项目评审”课程。
一个没有腿的因纽特石堆只是一堆石头。同样，如果只学习项目规划与评审，而没有从根本上理解流程和需求的重要性，就会形成一种追逐移动目标、产生大量忙碌却收效甚微的管理风格。
最后，每个因纽特石堆都需要一个头部。在这个专项课程中，拼图的最后一块将是专项顶点课程。在这里，你将应用在之前课程中学到的所有概念。
顶点课程是一个为期六周的项目，你将为一个模拟的软件开发团队进行评估和决策，目标是为一个要求苛刻的客户创造产品。为了参加顶点课程，你需要完成所有先修课程。
完成所有先修课程和顶点课程后，你将获得软件产品管理证书。
此证书是你完成所有认证所需工作的证明。
每个模块的工作量预计为2到4小时，每个模块的内容大约相当于一周的学习量。虽然工作量不大，但这并不意味着本课程内容不多。这个估计是基于我们为你准备的视频时长，以及所有的阅读材料和评估。
我们将发布额外的阅读资源供你参考。我们建议你尽可能多地查阅这些资料，以便充分利用与我们共度的学习时光。你在这门课程上投入越多，收获就越大。
我们在这里为你提供一切可能的资源，使你能够轻松地从本专项课程中获得最大收益。此外，课程设有讨论区，你可以在其中写下关于课程的任何问题或评论，请务必使用它。你的同学以及课程助教都将非常乐意帮助你澄清任何不明白的地方。
在整个课程中，你将需要完成周期性的测验。这些测验旨在帮助你保持专注和进度，并让你有机会检查刚刚学到的知识。与课程期末考试不同，这些测验不计入你的专项课程最终成绩。
在之前的课程中，我们已经简单讨论了我们希望从专项课程中获得什么。值得重申的是，我们希望让你对自己的软件产品管理技能充满信心。我们将为你提供获得这些技能所需的所有资源。但如果你有任何不清楚的地方，请不要犹豫，在课程讨论区提出该问题。
知识检查
以下关于软件项目的说法，哪一项是正确的？
A. 软件产品的功能必须在开发开始前全部确定，且一旦开发启动就不得更改。
B. 客户只有在开发完全结束后才能看到软件产品。
C. 项目管理计划一旦确定，就应坚持执行，不得再做更改。
D. 敏捷软件开发类似于黑客行为，不需要规划。
答案：以上选项均不正确。
对于软件产品，变化是持续发生的，以应对新的需求和机遇，因此选项A和C是错误的。客户应在开发过程中参与并提供反馈，而不仅仅是在最后，因此选项B是错误的。最后，敏捷软件开发是一套有纪律的实践，包含规划和特定规则，因此选项D也是错误的。
接下来，让我们开始我们的第一个作业。
这是一个向班级介绍自己并反思目前所学内容的好机会。请前往课程讨论区，写一段简短的自我介绍。向同学们介绍你自己、你的背景以及你学习本专项课程的原因。也请阅读一些同学的介绍，这有助于建立一个强大的学习社区。
我们的第一个模块到此结束。当你回来时，我们将深入探讨软件产品管理的更多具体内容，以及我们为什么首先需要它。下次见。
本节总结
在本节中，我们一起了解了软件产品管理专项课程的整体架构，它由六门课程组成，以导论课程开始，以顶点项目结束。我们学习了课程的学习顺序、每门课程的核心重点，以及如何通过讨论区和测验等资源来辅助学习。最后，我们通过一个知识检查问题，巩固了关于软件项目管理动态性和客户参与重要性的基本认识。
009：项目成功与敏捷的重要性
在本节课中，我们将要学习如何定义软件项目的成功，并探讨为何采用敏捷实践是实现这些成功目标的关键。
欢迎来到软件产品管理课程介绍部分的后半段。模块二是你迈向软件产品经理道路的下一步。我是摩根·帕策尔，将是本课程的讲师之一。我对软件产品管理有浓厚的兴趣，并非常期待向你们传授相关知识。我拥有软件开发背景，并亲身体验过本专项课程中将涵盖的有效方法及其缺失的情况。让我告诉你，它们带来了巨大的差异。正是看到了这种差异，促使我投身于软件产品管理。因此，我期待带领你们学习这些课程，让你们也能看到这种差异。
在这个模块中，你将预览整个专项课程的内容。这将是你成为软件产品管理专业人士道路上的路线图。在本模块结束时，你将理解我们选择呈现这些主题的原因，以及它们将如何在你作为软件产品经理的职业生涯中使你受益。
首先，我们来谈谈一种名为“敏捷”的实践。敏捷实践是一系列指导原则，旨在说明应如何进行软件开发以获得最佳结果。敏捷涵盖了产品经理工作的很大一部分。事实上，我们在本专项课程中将涵盖的大多数概念都是敏捷的一部分。在本课中，我将介绍项目成功的含义，以及为何你应该使用敏捷。我先透露一点：成功与敏捷直接相关。我们将在下一课以及关于软件过程和敏捷实践的课程中更详细地讨论敏捷，所以现在，你我将只讨论为何使用敏捷很重要。
在开始讨论敏捷之前，我们先谈谈项目成功。软件产品管理专业人士通常使用进度、预算和用户需求作为定义成功的基准。
以下是定义成功项目时最常考虑的因素，请选择你认为最具代表性的一个或多个：
- A. 按时完成
- B. 预算内完成
- C. 满足需求
2013年由Scott Ammbler and Associates进行的一项调查询问了参与者如何定义成功。如果你的定义是按时交付项目，那么这与58%的受访者观点一致。这意味着超过一半的受访者认为按时完成是项目成功的重要因素。36%的人认为项目在预算内交付是重要因素。只有14%的人认为按照规格构建对于交付成功项目是必要的。而仅有8%的受访者认为一个成功的项目应该同时满足按时、按预算和符合规格。
同样值得注意的是，30%的参与者表示按时完成是决定项目成功的唯一因素。9%的人说预算内是唯一因素。有趣的是，每100人中只有一人认为项目按规格完成是唯一重要因素。你可以在我们的课程资源中找到这项研究的链接，我建议你查看一下。
是否存在其他定义成功的方式呢？比如通过开发人员的满意度？有时我们很容易忘记软件是由人创造的。这些应用程序和程序几乎像是凭空出现的。但在幕后，开发团队花费了无数时间和许多不眠之夜来生产这些产品，所以他们的满意度难道不应该算作成功的一部分吗？我的意思是，没有他们，就没有产品。尽管关于开发人员满意度的统计数据似乎更难找到，但这难道就降低了它的重要性吗？
项目成功也可以通过发布后的缺陷数量、发布后所需支持、产品的客户评分、产生的收入或客户满意度来衡量。无论你决定如何衡量项目成功，敏捷都可以帮助你实现它。
既然我们已经讨论了如何衡量成功，那么你认为对于一个成功的项目来说，最重要的因素是什么？
- A. 一个好点子
- B. 一个有才华的开发团队
- C. 一个商业模式
- D. 资金
- E. 时机
多家初创公司创始人比尔·格罗斯的一场TED演讲表明，发布的时机是商业成功最重要的因素。一个好点子需要有想要和需要该产品的客户。因此，E是正确答案。如果你想观看这场TED演讲，可以在我们的课程资源中找到，我强烈推荐。
你是否曾见过有程序员在混乱、不断被打断的工作环境中如鱼得水？反正我没见过。
敏捷带来了专注，确保你的项目以稳定、可管理和高效的节奏发展。这可以防止程序员被项目压垮，结果是拥有快乐且高效的程序员。
敏捷实践也鼓励频繁且一致的测试，这有助于减少缺陷。
敏捷实践鼓励与客户沟通，让客户参与整个项目过程，这为客户提供了透明度。这确保了客户得到他们要求的东西，或者更好的是，得到他们甚至未曾想象过的东西。你的开发团队的目标是满足你的客户，即使是最出色的产品，如果不能满足客户的需求和期望，也会功亏一篑。
请记住，成功不是终点，尤其是在软件开发中，失败也未必是致命的。美国实业家亨利·福特说过：“失败仅仅是重新开始的机会，这次要更明智。”软件开发就是关于迭代和演进，仅仅因为你一周成功或失败，并不能保证下一周会一样。软件不断变化，所以我们必须能够适应。
或许你现在能看出，项目成功更像是走在一条道路上，而不是停留在目的地。敏捷实践将影响整个开发过程，这最终会创造出更好的软件、更快乐的开发者和更满意的客户。
当你学习敏捷并对其实践建立信心时，你正在培养许多大型科技公司所需求的技能。像Adobe、亚马逊、微软和雅虎这样的公司都在使用一种名为Scrum的流行敏捷方法论。我将在关于软件过程和敏捷实践的课程中带你了解Scrum的实践。
现在，你已经扎实地理解了敏捷实践如何影响项目成功。在下一课中，我们将更深入地探讨敏捷的原则。
本节课中，我们一起学习了如何从不同维度（如进度、预算、需求、团队满意度等）衡量软件项目的成功，并深入探讨了敏捷实践在实现这些成功目标中的核心作用。敏捷通过提供稳定节奏、鼓励测试与沟通，能够帮助团队创造更好的产品，同时提升开发者和客户的满意度。
010：敏捷宣言 🚀
在本节中，我们将学习敏捷软件开发的核心思想——敏捷宣言。我们将了解它的起源、四大核心价值，并探讨如何在项目管理中应用这些理念。
上一节我们介绍了敏捷实践相较于随意管理方法的优势。本节中，我们来看看敏捷的具体定义和其核心价值。
敏捷宣言诞生于2001年，当时17位软件领域的专家聚集在一处滑雪胜地，共同探讨如何更好地管理软件开发过程，以创造出优秀的软件。这个重要的团体需要一个响亮的名字，于是他们被称为“敏捷联盟”。他们确立了关于软件开发中最重要事项的四大核心价值陈述。为了进一步阐述这些核心价值，联盟还一致同意了12条支持性原则。
以下是他们提出的四大核心价值：
- 个体和互动高于流程和工具。
- 可工作的软件高于详尽的文档。
- 客户合作高于合同谈判。
- 响应变化高于遵循计划。
这意味着，虽然右侧的项目仍有价值，但我们更重视左侧的项目。当敏捷联盟说他们更重视左侧的项目时，并不是建议你忽略流程和工具、详尽文档、合同谈判或遵循计划。他们是在建议，左侧的项目是更值得关注的重点。
为了帮助理解，让我们看一个案例。
保拉一直在为“真北航空航天系统”公司管理一个新数据库系统的开发。每两周，她都会邀请客户参加一个周五下午的会议，开发团队在会上演示最新的产品原型。本周的会议促使客户和开发团队讨论了一个新的用户界面功能，该功能将允许用户轻松地向数据库输入信息。保拉记录了新的需求，并提醒自己安排一次与法务团队及客户的会议。签署修订后的合同是必要的，以便团队获得新功能的书面规范。
请判断保拉在哪些方面符合敏捷宣言的价值观：
A. 定期演示新的原型。
B. 开发团队与客户有面对面交流的时间。
C. 随着新需求的识别，产品不断演进。
D. 更新合同以明确新功能。
答案分析：
- 选项A符合“交付可工作软件”的敏捷价值。
- 选项B符合“客户合作”和“个体与互动”的敏捷价值。
- 选项C符合“响应变化”的敏捷价值。
- 保拉的做法不符合“客户合作高于合同谈判”的敏捷价值。尽管她鼓励与客户频繁、开放的沟通，但她认为必须修订合同，开发团队才能知道已商定的功能规范。
现在，让我们详细解读宣言中的四大核心价值。
价值一：个体和互动高于流程和工具。
你的开发人员和客户在协作关系中会更高效、更有成效。作为产品经理，你不是一个传信员，你需要促进想要产品的人（客户）和制造产品的人（开发团队）之间的沟通。
价值二：可工作的软件高于详尽的文档。
请记住，宣言指出右侧项目仍有价值。因此，文档仍应在整个项目中持续创建。但当面临艰难抉择时，一个可工作的软件远比一份描述软件应该做什么的文档有价值得多。核心在于 可运行的代码 > 厚厚的需求文档。
价值三：客户合作高于合同谈判。
这意味着你需要与客户培养一种积极的关系，这种关系更关注他们想要什么，而不是过分拘泥于合同条款。客户是设计的中心，确保他们的愿景得以实现至关重要。
价值四：响应变化高于遵循计划。
软件是不断变化的，以易于响应变化的方式来开发软件非常重要。在你学习后续四门基础课程的过程中，你将学到许多使项目更易于应对变化的敏捷实践。
现在你可能会想，在你的项目中实施其中一项或多项价值可能不切实际。这没关系，敏捷是灵活的。重要的是，你去实施那些确实行之有效的价值。
本节课中，我们一起学习了敏捷宣言的起源和其四大核心价值：重视人与协作、重视可交付的成果、重视与客户的伙伴关系以及重视适应变化。理解这些价值观是实践敏捷软件产品管理的第一步。
011：交付可工作软件
在本节中，我们将学习敏捷宣言中关于“交付可工作软件”的核心原则。这些原则指导团队如何通过持续交付有价值的软件来满足客户需求。
上一节我们介绍了敏捷宣言的价值观，本节中我们来看看支撑这些价值观的12条具体原则。这些原则被分为三大类：交付可工作软件、灵活设计及适应变化、协作沟通与组织。我们将首先探讨第一类原则。
聚焦于交付可工作软件
以下原则的核心是确保团队始终以交付可工作的、有价值的软件为最高目标。
-
最高优先级是通过尽早和持续交付有价值的软件来满足客户。
在此原则中，“有价值”一词至关重要。你需要询问客户他们认为什么是有价值的。客户最看重的功能应成为开发团队的最高优先级。 -
欢迎需求变化，即使在开发后期。敏捷过程利用变化为客户创造竞争优势。
软件需求是不断变化的，你必须为此做好准备。一个对变更友好的项目意味着项目能轻松适应变化。 -
频繁地交付可工作软件，周期从几周到几个月不等，且倾向于较短的周期。
可以这样理解：软件交付越频繁，客户就有越多的机会对开发过程提供反馈。 -
可工作的软件是衡量进度的主要标准。
既然团队专注于交付可工作软件，那么进度就应该以此为标准来衡量。这里提到的“可工作软件”意味着一种完成度。在敏捷中，一个功能只有在所有代码都已编写、测试并完成文档后，才能被视为完成。你需要确保开发团队是在完成功能，而不是开了很多头，却很少真正做完。
如何构建对变更友好的软件产品
为了使你的软件产品更能适应变化，可以考虑以下实践。我们将在后续课程中更详细地回顾这些实践。
- 频繁的客户沟通
- 有良好注释的源代码
- 持续审查和改进项目
- 及时更新的、排好优先级的待办功能列表
- 对变化持开放态度的开发团队
本节课中我们一起学习了敏捷宣言中关于“交付可工作软件”的四条核心原则，并了解了如何使项目更能适应变化。下一节，我们将探讨关于“灵活设计及适应变化”的原则。
012：灵活的设计 🛠️
在本节中，我们将学习敏捷开发中关于灵活设计和适应变化的核心原则。我们将探讨如何通过拥抱变化、追求技术卓越、保持可持续的开发节奏以及崇尚简洁，来构建更具韧性和响应能力的软件产品。
上一节我们介绍了敏捷开发中以人为本的原则，本节中我们来看看另一组专注于灵活设计和适应变化的原则。
正如之前所述，变化在软件开发中是不可避免的。你需要以一种使变化不会造成损害的方式来规划项目。使产品更能响应变化的一个好方法是拥有灵活的设计和可适应的流程。
我将从第四个原则开始这一部分，它关乎需求的变化。这一原则将在后续的“客户需求与软件需求”课程中详细讨论。
该原则指出：即使在开发后期也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
变化最终会创造出更好的产品，它能满足你的客户，并为你的产品带来竞争优势。
接下来这个原则谈到了良好的开发实践。它指出：持续关注技术卓越和良好设计能增强敏捷性。
拥有可读性强、简洁的代码和更灵活的设计，将使变更更容易实施。良好的设计可以让你了解哪些组件是相互依赖的。
下面我们将要审视的原则是关于可持续发展的。它指出：敏捷过程倡导可持续发展。发起者、开发者和用户应该能够长期维持稳定的开发节奏。
如果你曾在软件开发领域工作过，可能对在截止日期前赶工的糟糕情况并不陌生。这种不稳定的节奏会导致开发团队精疲力竭，并对项目成功产生负面影响。
我们已经进行到一半了，让我们继续前进，谈谈第七个原则，它关乎简洁性。
该原则指出：简洁——即最大化未完成工作量的艺术——是根本的。 这并不意味着敏捷就是交付得更少，而是意味着敏捷专注于交付本质内容，减少不必要的工作。
这意味着编写更少的代码和文档，专注于交付一个尽可能简单的高影响力产品。
以下是关于“简洁”原则的一个案例分析：
山姆是你开发团队中的一名开发人员。他痴迷于敏捷的简洁概念。他编写的软件代码非常精简，只完成它应该做的工作，没有任何不必要或复杂的代码。他也不添加注释来记录他的代码。山姆认为团队应该只开发使产品运行所必需的功能，而不应该把时间浪费在客户认为能为产品增加价值、但他认为无用的花哨功能上。他拒绝参与编写详尽的文档，但会写下他如何开发该功能的笔记、任何关键要点以及给最终用户的简短培训文档。
你认为他的哪些做法（如果有的话）真正遵循了敏捷宣言中的简洁概念？
A. 满足所需功能的最精简代码。
B. 代码中没有注释。
C. 只开发基本功能。
D. 必要的文档而非详尽的文档。
山姆对简洁的看法并不完全符合宣言的建议。但他在某些方面是正确的。
- 最精简的代码是专注于简洁的好方法。
- 代码中的注释有助于解释特定解决方案的原理。使用注释可以使代码更容易与其他开发人员共享，这是为项目添加少量但有效文档的简单方法。
- 此外，团队开发功能不应基于自己对重要性的判断标准，而应基于什么能满足客户。如果功能能为产品增加价值并且是客户需要的，那么就应该实施。作为产品经理，你可能需要解释某些功能为何能增加价值。
- 然而，他的文档风格是将必要信息传递给正确人员的好方法。可能不需要全面的文档，简短简洁的文档反而可能鼓励人们真正去阅读它。
因此，A和D是正确答案。
在本节课中，我们一起学习了敏捷宣言中关于灵活设计的核心原则：拥抱变化以获取竞争优势、通过技术卓越和良好设计提升敏捷性、保持可持续的开发节奏，以及崇尚简洁的艺术。理解并应用这些原则，有助于我们构建更能适应变化、更高效且更可持续的软件产品。
013：协作式沟通 🗣️
在本节中，我们将学习敏捷开发中关于协作式沟通与团队组织的核心原则。这些原则旨在促进团队内部及团队与客户之间的有效沟通，从而推动卓越的软件开发。
上一节我们探讨了敏捷的核心价值观，本节中我们来看看支撑这些价值观的具体原则，特别是关于沟通与协作的部分。
原则八：信任与赋能
第八条原则强调了信任的重要性。其表述如下：
围绕积极主动的个体构建项目。为他们提供所需的环境和支持，并信任他们能够完成工作。
这意味着，作为产品经理，有时需要退后一步。这或许不易做到，但重要的是更多地扮演团队促进者的角色，而非控制者。乔治·S·巴顿将军曾说过：“告诉人们目标，而非方法，你会对结果感到惊讶。”
原则九：自组织团队
下一条原则是关于自组织。其表述如下：
最好的架构、需求和设计出自自组织团队。
敏捷鼓励团队进行自组织。这意味着团队作为一个整体，自行决定如何组织项目，包括诸如分配任务和选择使用工具等事项。
原则十：紧密的客户-开发者协作
我们已接近尾声，第十条原则关注客户与开发者的沟通：
业务人员和开发者必须在整个项目期间每天一起工作。
😊 再次强调，作为产品经理，你将扮演促进者的角色，但绝不应成为双方之间的传话筒。
原则十一：面对面沟通
倒数第二条原则是关于沟通方式：
向开发团队传递信息以及团队内部沟通，最有效且高效的方法是面对面交谈。
😊 能够直接与项目团队成员交谈，可以减少误解的机会，并提高工作推进的速度。
以下是关于实施此原则的建议：
- 如果团队具备同地办公的条件，应充分利用这一点，进行频繁而简短的面对面会议。
- 当团队分布在全球时，应使用视频会议等沟通工具。虽然效果不及面对面交流，但尽力而为至关重要。😊
原则十二：定期回顾与调整
最后但同样重要的一条原则是关于回顾已完成的工作：
团队定期反思如何能变得更高效，并相应地调整其行为。
你的流程与你正在创造的产品非常相似：你需要测试你的流程、回顾它们并进行改进。敏捷培训师兼作者亨德里克·克努伯格曾说：“重要的不是你的流程，重要的是你改进流程的流程。”
流程与编写代码非常相似。一个首次就完美的流程，等同于一个首次编译就毫无缺陷的程序——这是不可能的。
知识应用：自组织团队实践
假设你在一家为航空公司开发应用程序的全球性企业工作。你最新的项目是管理一个取代飞机上电视屏幕的娱乐应用的开发。你的开发团队在开发和敏捷实践方面都经验丰富，他们实行自组织。
那么，这个自组织团队实际上是什么样子的？请选出所有适用的选项。
A. 产品经理无事可做。
B. 他们已商定要遵循的某些实践。
C. 他们决定在完成任务时自行分配新任务。
D. 他们任命了一位负责团队的领导者。
B和C是团队实现自组织的绝佳方式，也是正确答案。自组织团队旨在鼓励沟通、团队合作、高效开发、积极性和相互尊重。
任命一位领导者并不能让每个人都处于同等的尊重水平，也无法鼓励平等的责任感。一个自组织团队也并不意味着你无事可做；你的职责是管理并指导他们实践自己选择的工作方式。
总结与前瞻
现在你已经了解了敏捷宣言及其原则，你可能会想，我给出了所有这些原则，但还没有提供应用它们的具体方法。
在本专项课程中，你将学习的大多数概念和实践都将与一条或多条敏捷原则相关。到本专项课程结束时，你将掌握工具和知识，能够自信地将这些原则应用到你的项目中。
为了从本课程中获得最大收益，建议你重温敏捷宣言，并将后续课程中学到的内容与本课介绍的原则及核心价值观联系起来。如果你有兴趣了解更多关于敏捷宣言的信息，可以访问 agilemanifesto.org。
本节课中，我们一起学习了敏捷开发中关于协作沟通与团队组织的核心原则，包括信任、自组织、紧密协作、面对面沟通以及持续改进。 这些原则共同构成了高效敏捷团队的基础。
既然你已了解这些敏捷原则，接下来就需要将它们应用到具体事务中。每一个优秀的项目都离不开流程。在我们的下一课中，你将学习为什么流程对产品管理和开发如此重要。我们下节课见。
014：为什么需要流程
在本节课中，我们将要学习为什么在软件开发中需要一个明确的流程。我们将探讨流程的定义、其包含的阶段，以及一个良好流程如何帮助团队避免混乱、提高效率并最终交付成功的产品。
上一节我们介绍了敏捷宣言的价值观和原则，本节中我们来看看如何将这些原则以实际的方式应用到项目中。
一个流程是应用这些原则的良好基础。流程将人们的工作组织成不同的阶段或步骤，以开发一个软件产品。
以下是你在思考软件开发时可能会想到的一些阶段：
- 规划项目。
- 编写代码。
- 测试软件。
- 维护产品。
这些是一些例子，但你可以用许多方式来构建开发流程。在后续的“软件流程与敏捷实践”课程中，你将探索几种组织软件开发流程的模型。
为了理解什么是阶段，让我们思考一个简单的问题：如果你要创建一个制作披萨的流程，你认为阶段可能是什么？
A. 饼皮、酱料、奶酪、意大利辣香肠。
B. 规划、准备、组装、烹饪。
C. 拨打、订购、吃、剩菜。
D. 制作、烘烤、吃、吃剩菜。
A不正确，因为这些更像是原料而非可执行的阶段。C可能是正确的，但前提是我们创建的是订购披萨的流程，而不是制作披萨的流程。D不正确，因为它包含的是低层次的动作，而非阶段。因此，B是正确答案，因为它包含了规划、准备、组装和烹饪这些高层次阶段。
尽管在产品生命周期中组织工作的流程多种多样，但它们通常共享“阶段”这个高层次概念。阶段的例子包括：需求规格说明、设计与实现，以及验证与确认。
- 需求规格说明是构思产品创意的阶段。当你能够明确软件将要做什么时，你就知道需求规格说明阶段已经完成。
- 设计与实现是找出构建软件最佳方式的阶段，这允许有效的设计和编码工作开始。
- 验证与确认是你测试软件缺陷并确保系统交付了客户所需功能的阶段。
流程对于组织你的开发工作并确保你以逻辑顺序完成任务是必要的。它们还能确保步骤不被遗漏或忽视。当你不知道从何开始时，软件开发是相当艰巨的，流程也为你应该从项目的何处开始提供了清晰性。
让我们通过一个练习来巩固对阶段的理解。假设你是一个开发新视频游戏项目的产品经理，你的团队负责角色选择界面。
你的团队需要完成的一些任务包括：
- 为选择角色编写测试。
- 规划角色的外观。
- 为多人选择编写源代码。
- 为更改角色颜色执行测试。
那么，哪些任务属于验证与确认阶段？
A. 为选择角色编写测试。
B. 规划角色的外观。
C. 为多人选择编写源代码。
D. 为更改角色颜色执行测试。
为选择角色编写测试和为更改角色颜色执行测试都有助于评估产品是否按预期方式工作。因此，答案A和D是验证与确认阶段的一部分。
现在，让我们思考一下没有流程的软件开发会是什么样子。想象你有一个很棒的应用创意，如果你仅仅凭想象就开始直接编码，这就像坐在键盘前，期望一部伟大的小说能从你的指尖自动打出来。这通常被称为临时性开发。
你按时生产出好产品的机会非常渺茫，事实上，甚至可能是不可能的。临时性开发会带来许多不同的问题，一个主要的担忧是糟糕的设计。如果你的编程是随着想法在脑海中闪现而进行的，你将会花费大量时间开发构思不佳的功能，结果却在开发中途改变主意。时间是宝贵的，而重新开始是昂贵的。
通过一个设计良好且每个人都遵循的流程，你将能够监控项目的所有方面。这种可见性将帮助你有效地设定工作预期、管理风险、避免浪费资源，并交付一个经过深思熟虑的产品。当开发者理解流程时，他们也能够在开发早期更好地剔除缺陷或糟糕的设计。朝着共同目标共同努力将节省时间和金钱。
一个定义明确的软件流程也为开发团队中的每个人规定了角色和职责。采用软件流程似乎是产品开发的一个自然步骤，甚至流程会自然出现这一点可能看起来很直观，但遵循一个定义好的流程模型能让每个人都知道该期待什么。随着你在专业课程中的深入，你将熟悉许多行业标准的软件流程模型。
一个稳健的软件开发流程是你构建优秀软件的发射台。所有开发流程的第一步都是理解你要创造什么，也就是我们下一课的主题：初始软件需求。
本节课中我们一起学习了软件开发流程的重要性。我们定义了流程及其核心阶段（需求、设计、验证），并通过例子说明了流程如何帮助团队避免临时开发的陷阱，确保工作有序、高效地进行，从而为交付成功的软件产品奠定坚实基础。
软件产品管理课程1：1.2.4：为什么需要需求
🎯
我是布拉德利·普莱特。我曾在多个软件项目中担任项目经理，并在阿尔伯塔大学广泛学习了该领域的相关技术。我对软件产品管理充满热情，并很高兴能与您分享这份热情。
在本节课中，我们将探讨为什么需求在软件项目中至关重要。我将首先概述我们需要需求的主要原因，并举例说明当您忽视这些需求时会发生什么。
那么，让我们从为什么需要需求开始。
需求是对客户需求的一组具体描述。我将在后续的“客户需求与软件需求”课程中更详细地介绍这一点。目前，您只需知道客户是最初希望构建软件产品的人或群体。
需求与流程相结合，是任何成功软件项目的支柱。那么，是什么让它们如此重要呢？
以下是一个优秀社交网络应用的需求列表示例：
- 用户可以在其数据中存储用户档案。
- 向其他用户发送消息。
- 查看其他用户的档案。
- 创建状态更新。
- 查看其他用户的状态更新。
这是一个相当简单的例子，但您应该明白了：需求决定了软件产品的功能。
那么，如果您收到一个看似简单的请求，比如“用户可以通过应用相互交谈”，会发生什么？这如何转化为需求？用户是否应该能够相互发送语音便笺、文本消息，还是脑电波？还有“可以”这个词，用户是否只能在一天中的特定时间相互交谈？
这种模糊性会给开发人员带来巨大的困惑，特别是如果大多数用户需求都同样不明确。您需要获取更多细节才能真正确定下来。
在软件开发中，避免混淆极其重要。这始于知道如何正确地获取和表达需求。
通过花时间细化需求，您还可以在产品构建之前就发现潜在的错误。通过澄清想法，开发变得专注且高效。
这里有一个例子。您的一位开发人员已开始开发这个社交网络应用，并遇到了这个需求：“用户必须能够以访客身份发送消息。”
开发人员可能会根据这个需求设计一个系统，让用户可以选择登录自己的账户或使用访客账户。一个单一的访客账户满足了需求，但是当许多不同的用户都可以访问同一个访客账户时，是否会产生意想不到的后果？
由于开发人员对需求的理解，这个访客账户变成了一个大账户，任何人都可以在其中给任何人发消息并查看对话。这个不幸的设计错误是需求定义不清的结果。
想象一下，构建一个考虑不周的功能会投入多少时间和精力。实现它会很昂贵，而修复它则更加昂贵。
让我们看看您是否能找出需求在软件开发中如此重要的关键原因。
在下面的测验中，请选择您认为最能说明为什么需要需求的选项。
您正在与客户合作，为软件产品获取一组需求。客户拿出一张餐巾纸，在上面勾勒了一个具有几个概要功能的应用草图。他说：“这就是我们想要的产品。”如果您接受这份文件作为最终需求集，而不是与客户一起细化它们，您的项目可能面临以下哪些潜在风险？
A. 产品实现错误可能直到软件编码完成并测试后才会显现。
B. 产品可能无法满足最终用户的需求。
C. 客户对产品的外观和感觉有过多意见。
D. 相关人员缺乏协作，士气下降。
答案是 A、B 和 D。
客户对产品的外观和感觉有过多意见并不是产品风险。客户在流程中的参与度越高，事情往往进展得越顺利。这并不是说您应该让客户完全控制开发，而是应该协作以创造最佳产品。协作也有助于提高士气，一个快乐的团队往往能更快地完成任务。
要了解更多关于如何确保充分利用需求的信息，我鼓励您学习 Coursera 上本专项课程中的“客户需求与软件需求”课程。
在下一节课中，摩根将讨论为什么需要花时间规划项目。感谢观看。
本节课总结
在本节课中，我们一起学习了需求在软件项目管理中的核心重要性。我们明确了需求是客户需求的具体描述，是决定产品功能的基石。通过具体示例，我们看到了模糊需求如何导致开发混乱、设计错误以及巨大的时间和成本浪费。最后，我们通过测验巩固了认识：清晰、细化的需求有助于避免实现错误、确保产品满足用户，并促进团队协作与士气。忽视需求提炼将直接带来这些项目风险。
016：为什么要计划 📝
在本节中，我们将探讨计划在软件产品管理中的核心作用。我们将了解计划如何帮助我们将未来带入当下，从而更好地管理时间、资源和风险，最终提高项目成功的可能性。
艾伦·拉肯是一位以个人时间管理书籍而闻名的作家。
他说，计划是将未来带入当下，以便你现在就能为此做些什么。
一个计划突出了现在可以做什么，它推动你朝着未来的目标前进。
计划涉及使用流程和需求来开始组织任务和排期。创建任务和排期需要确定谁应该做这项工作，并估计这项工作需要多长时间。
需求写得越差，准确的时间估计就越困难。需求越具体，就越容易估计完成工作所需的时间。
上一节我们了解了计划如何帮助明确任务，本节中我们来看看，如果你的排期基于糟糕的时间估计会发生什么？
整个项目的时间线将无法实现。
想象一下，你高估了工作量，向客户提供了基于时间的估计和不准确的时间线。你夸大的项目会让客户认为你不理解项目，他们可能会将业务转移到别处。
或者想象一下，你低估了工作量，并向客户承诺他们的项目将在特定日期完成。在不产生额外费用的情况下，最可能的结果是你无法按承诺交付。
估计对于确保你不会对客户过度承诺也很重要。
如果你的所有估计都太小，你会错误地认为可以为产品添加很酷的额外功能。
过度承诺最初会让你的客户感到高兴，但当交付时间到来时，客户会感到失望。即使产品本身很棒，它仍然比你承诺的要少。
正如我们刚才所讨论的，估计和排期是良好计划实践的重要组成部分。拥有良好的估计可以降低项目风险。降低风险和提前计划都是风险管理的一部分。
以下是关于时间估计责任的一个思考练习：
你正在为一家本地初创公司工作，你已经完成了大部分计划，现在需要为开发任务进行时间估计。
你认为谁负责创建时间估计？选择所有适用的选项。
A. 开发人员。
B. 你，软件产品经理。
C. 客户。
D. CEO。
开发的时间估计由开发人员和软件产品经理共同决定。开发人员最清楚开发功能需要多长时间，但作为产品经理，你也可以提供另一种意见。因此，A和B是最正确的答案。客户和CEO可以确定目标日期，但他们通常对时间估计没有发言权。
风险管理是计划的最大好处。记住艾伦·拉肯的话：计划是将未来带入当下，以便你现在就能为此做些什么。如果你能预测未来的风险，并在当下采取措施来减轻它们，那么你的项目将有更高的成功机会。
以下是我们在计划阶段可以管理的一些风险示例：
第一，开发团队职责。 你可以为需要完成的工作以及由谁来完成制定计划，这将减少关于谁负责什么工作的误解。协调一致的工作有助于高效开发，并有助于建立稳定的开发节奏。这是敏捷宣言中提到的一个原则。
第二，软件发布缺陷。 有效的计划可以预留足够的测试时间，这将减少发布产品中的缺陷，并在发现重大缺陷时留出修复时间。
第三，错过截止日期和/或预算。 计划可以使开发保持在正轨上，从而减少资源浪费，这降低了项目延期和/或超支的风险。
以下是另一个场景练习：
你现在正作为一个项目的产品经理工作，该项目正在开发一个将在下一次太空任务中使用的通信应用程序。这个产品必须按预期工作，因此你花了很多时间与开发团队一起识别风险，并制定了一份潜在风险的长清单。
你认为在识别出潜在风险后，下一步应该做什么？
A. 照常继续开发。
B. 通知高管。
C. 制定风险计划。
D. 放弃。
如果你不采取任何行动，识别风险就是一个无用的过程。你的下一步应该是与可能受影响的人员一起制定风险计划，以便在问题确实发生时制定行动方案。因此，C是正确答案。
计划还可以帮助你预测可能发生的问题。你将能够为它们制定风险计划。以下是一些可能出错的事情的例子：
- 如果开发人员生病了怎么办？
- 如果有人辞职了怎么办？
- 如果你的客户联系人变了怎么办？
- 或者如果你的技术崩溃了怎么办？
你将如何处理这些问题？计划让你能够思考这些问题的解决方案，以便在它们确实发生时有所准备。
计划不仅仅用于项目的开始。在软件开发中，计划是在整个项目中持续进行的事情。软件总是在发展，你的计划必须灵活。当你有一个审查计划的流程时，你的项目会变得更加敏捷，这意味着你可以轻松适应变化。
最初，集思广益那些会对项目产生负面影响的场景可能看起来很耗时，但在没有计划的情况下，在紧急时刻对问题做出反应会更加耗时。在冷静和专注的状态下准备的任何解决方案，都会比在压力时刻的快速思考更好。
计划可以比作行人过马路。一个行人可以直接走进繁忙的街道，并希望一切顺利。除非别人注意到他，否则他很可能会被撞到。这相当于临时性的开发。
如果行人先检查车辆，然后在安全时再前进，他就能安全到达另一边。这与在开始开发时寻找风险是一样的。当然，总会有无法预见的风险，但通过寻找风险并在安全时前进，你增加了成功的机会。
在本节课中，我们一起学习了计划的重要性。我们了解到，计划通过将未来目标分解为当前可执行的任务来指导行动，而准确的时间估计是可行计划的基础。计划的核心价值在于风险管理，它允许我们提前识别潜在问题（如职责不清、缺陷、延期超支）并制定应对策略，从而降低项目失败的可能性。最后，我们认识到计划不是一次性的活动，而是一个需要在整个项目周期中持续进行和调整的动态过程，这有助于团队保持敏捷并适应变化。
在下一课中，布拉德利将在一个关于审查和监控开发进度的课程中，把所有流程、需求和计划整合在一起。
软件产品管理课程1：1.2.6：为什么要监控 🎯
在本节课中，我们将要学习在软件开发项目中，为什么在计划制定后，持续监控项目进展是至关重要的。我们将探讨监控的目的、好处以及它如何帮助团队避免常见陷阱。
上一节我们介绍了制定开发计划的重要性。本节中，我们来看看当计划开始执行后，产品经理需要做什么。
仅仅制定计划并让开发团队开始工作是不够的。为了确保项目按计划进行，产品经理必须主动监控、分析和评审项目进展。
考虑以下场景：你正在为客户做一个项目。你已经建立了开发流程，明确了需求，并完成了所有计划。开发团队正愉快地进行编码，一切似乎都按计划进行。几周、几个月过去了，现在距离截止日期只有两周。你看了看项目结束时仍需完成的工作，感到恐慌——至少还有一个月的任务量。你将不得不告诉客户无法按时交付。突然间，开发团队开始加班加点，办公室一片狼藉，开发人员疲惫不堪，产品质量急剧下降。客户因你未能遵守约定的截止日期而指责你。当一切似乎都很顺利时，你是如何陷入这种境地的？
遗憾的是，这种情况在软件开发中非常普遍。个人的忙碌并不足以确保有效的进展。仅凭“感觉良好”来衡量项目真实进度是不可靠的。如果你有过软件开发经验，很可能对“项目截止日期意外临近时出现的赶工现象”再熟悉不过了，这通常伴随着大量未完成的工作。如果你从一开始就监控项目进展，或许就能完全避免这种情况。
但不必担心，几十年来，软件开发社区已经建立了成熟的实践来避免上述问题。
既然你了解了监控进展的重要性，让我们看看你是否还记得一些原因。
以下是关于监控目的的一个思考题：
斯科特是一名软件产品经理。由于客户不断改变对产品功能的要求，并且他的开发团队工作速度不够快，他将错过一个主要截止日期。他对客户在项目中的“多管闲事”感到沮丧，并认为跟踪开发人员的个人工作将使他能够在他们表现不佳时采取纠正措施。
请选择斯科特通过监控能解决的问题：
A. 适应不断变化的产品需求。
B. 避免解雇效率最低的开发人员。
C. 不受客户干扰地工作。
D. 满足项目计划截止日期。
监控帮助我们适应变化并满足截止日期。 虽然监控进度允许你跟踪开发人员的工作效率，但它不应被视为评估其职业发展的方式。同时，它也不能替代与客户的良好沟通。因此，正确答案是 A 和 D。
监控进度只是我们确保项目健康的一种方式。它能让你轻松识别何时出现问题，并做出适当的调整来解决问题。你也能识别项目中进展顺利的部分，并庆祝这些小的胜利。这不仅能让项目保持在正轨上，提高交付给客户时的产品质量，还能提升团队士气，并在项目内部提供高度的透明度。
需要明确的是，透明度并不意味着跟踪开发团队的进度却对他们保密。透明度意味着团队中的每个人（而不仅仅是管理层）都知道项目的状态。当开发团队和产品经理以积极、目标驱动和基于团队的心态共同监控进展时，监控可以成为凝聚团队的一种方式。没有人喜欢赶工，而监控是团队可以用来互相帮助、避免熬夜和长时间加班的一种方法。
现在你已经了解了监控如何影响团队，让我们测试一下你的理解。
罗斯是一名产品经理，正与他的开发团队进行一个项目。他选择在整个项目中分享他所跟踪的细节，以便让整个团队都了解情况。
他正在实施监控的哪个方面？
A. 协作
B. 可见性
C. 验证
D. 确认
可见性是我们用来描述团队中每个人都知道项目状态的词语。这使得 B 成为正确答案。虽然监控通常会因更多的讨论而促进开发团队内部的协作，但罗斯在这里并非专门实施这一点。验证和确认用于描述软件工程的其他协作方面，而非此处的场景。
因此，监控进度的核心在于按时并按规格交付产品的理念。这当然有助于开发出更好的软件，并最终让客户更满意。
但监控的意义远不止于在紧张的时间表下创造出色的产品。如果做得好，监控可以成为一种极佳的方式，来建立共同的目标感，并让你的开发人员感受到自己是紧密团结的团队的一部分。
如果你想了解更多，我鼓励你加入本专业课程的最后一门课，在那里我将深入探讨你可以用来监控和评审项目的具体方法。
总结
在本节课中，我们一起学习了为什么监控是软件产品管理的关键环节。我们了解到，仅靠计划和感觉无法保证项目成功，主动监控可以帮助我们：
- 适应需求变化。
- 确保按时交付。
- 提前发现问题并调整。
- 提升团队士气与透明度。
- 避免有害的“赶工”现象。
有效的监控不仅是管理工具，更是促进团队协作、实现共同目标的重要手段。
018：《软件产品管理简介》｜课程概览
在本节课中，我们将要学习艾伯塔大学软件产品管理专项课程的总体介绍，了解课程的目标、内容结构以及学习完成后你将获得的技能。
大家好，我是乔纳森·舍费尔，一名计算机科学家，现任艾伯塔大学理学院院长。
我很荣幸地向大家介绍艾伯塔大学计算机科学系开发的软件产品管理专项课程。
这套系列课程将教你如何成功地引导一个软件产品从构思到交付的整个开发过程。
艾伯塔大学被公认为世界领先的公立研究型与教学密集型大学之一。作为加拿大顶尖大学，我们在科学、人文、创意艺术、商业、工程和健康科学等领域均以卓越著称。我们的热情在于为学生成功提供起点，目标是激励、转变和提升我们的学生，并帮助他们实现目标。
强大的协作与沟通技能，对于复杂软件的开发至关重要，正如它们在我们生活的许多领域一样。考虑到这一点，我们的计算专家团队将为你提供掌握敏捷软件开发所需的过程与实践方法。
我们对软件产品管理流程的实战理解，将为你提供直面挑战所需的一切。我们将教你如何理解并优化客户的软件需求，以及如何将这些需求传达给开发团队。
以下是本专项课程的核心学习内容：
- 你将学习从监控项目到确保其符合客户需求、遵循项目计划并达到预期质量水平的技术。
- 你将有机会加入一个软件产品管理社区，在那里你可以分享经验并从他人的见解中学习。
最后一个课程是一个为期六周的毕业项目，它将为你提供在真实模拟环境中应用这些管理技术的机会。成功完成毕业项目后，你将获得认证，并为在软件产品管理职业生涯中脱颖而出做好准备。
我们很高兴你对学习我们的专项课程感兴趣。我们已经尽力使这成为一个有价值的教学体验。
现在轮到你了。祝你好运。
本节课中，我们一起学习了艾伯塔大学软件产品管理专项课程的总体框架。我们了解到，该课程旨在通过一系列理论与实践相结合的教学，培养学员从需求分析到产品交付的全流程管理能力，并最终通过一个实战毕业项目来巩固所学技能，为职业发展做好准备。
019：《软件产品管理简介》 🚀
在本课程中，我们将学习软件产品管理的基础知识。这是软件产品管理专项课程的第一门课，也是最短的一门。通过本课程，你将了解软件产品经理的角色、敏捷开发的核心概念，并为后续深入学习打下基础。
课程目标与结构 📋
上一段我们介绍了课程概况，本节中我们来看看课程的具体目标与安排。
本课程是软件产品管理专项课程的第一门课，也是课时最短的一门。
在最初的两周里，我们将达成以下目标：
以下是本课程的核心学习目标：
- 描述软件产品经理的角色。
- 展示对软件产品经理及其行业同事的访谈。
- 解释敏捷软件开发的核心内容。
同时，本课程会让你对专项课程后续将涵盖的主题有一个整体的认识。
在本入门课程结束时，你将能判断这个专项课程是否符合你的个人学习目标。
课程难度与受众 🎯
了解了课程目标后，本节我们来讨论课程的难度设置及其面向的受众。
如果你具备软件开发背景，你可能会觉得本入门课程中介绍的技术信息比较基础。
但对于软件领域之外的学习者，本课程将提供一些关键术语和概念，这些内容对学习后续课程至关重要。
如果你在学习本课程后感到意犹未尽，请继续学习我们专项课程中的下一门课。
优秀产品经理的特质 👂
前面我们讨论了课程本身，现在让我们聚焦到软件产品经理这个角色本身应具备的关键特质。
一名高效的软件产品经理必须是一名优秀的倾听者。
他需要能够从可能无法完全表达或理解自身需求的用户那里，构想出有价值的产品。
成为一名好的倾听者，就如同成为一名主动的学习者。当你对学习持开放态度时，即使只学到一件新事物，也可能极大地改变你对世界的理解。
总结与展望 🌟
本节课中我们一起学习了软件产品管理入门课程的目标、结构、适宜人群以及优秀产品经理的核心特质。
我们希望你在深入探索软件产品管理专项课程的过程中能学到许多东西。
我们期待在论坛中听到你的观点。
020：课程概述与核心概念
在本节课中，我们将要学习软件产品管理的基础知识，了解其重要性，并认识构成优秀软件产品的三个核心视角。
大家好，欢迎来到Coursera的软件产品管理专项课程。我是Ken Wong，阿尔伯塔大学计算机科学系的副教授，我的专业领域是软件工程。在本专项课程中，我的目标是帮助你成为一名自信、合格的软件产品经理。如果你已经是一名软件产品管理专家，那么我的目标是让你在工作中表现得更加出色。
你们中的一些人可能已经参与过某种软件产品的开发。回顾你的经验，它是一个成功的项目吗？项目是否可以做得更好？我猜大多数人会回答“是的”。本专项课程将向你展示如何与客户合作，并组织开发团队来打造更好的软件产品。
既然你已经知道项目可以做得更好，那么请花点时间思考一下，作为一名软件产品经理，你希望提升自己的哪些方面。当然，你可以精进许多技术技能，比如特定的平台、语言和工具。但除此之外，还有更多内容。让我们一起来探索。
我已经提到，你将与一个开发团队合作。在整个专项课程中，我们会多次讨论这一点。
以下是关于开发团队构成的思考题，你可以选择多个答案：
- A. 程序员、编码员或开发者
- B. 客户
- C. 用户界面专家和图形设计师
- D. 质量保证专家或测试员
你将合作的每个开发团队都是不同且独特的。通常，一个开发团队由编码人员、创意设计师和测试人员组成。因此，最正确的答案是A、C和D。尽管你和你的开发团队将与客户紧密合作，但客户通常不被视为开发团队的一部分，所以答案B被排除在外。
如今，要打造出色的软件产品，需要许多拥有不同技能的人持续协作。但他们应该如何组织？团队可以遵循哪些实践来让工作更有章法、减少随意性？我们开始进入软件产品经理的领域了。
让我们思考一些其他你可能会感兴趣的问题。我们需要更聪明地工作，而不仅仅是更努力。存在各种各样的问题：当需要协调许多团队成员时，当需要开发大量功能时，当项目预计持续数年时，我们如何管理这一切？我们也不能忘记我们真正要解决的问题是什么，即客户在软件产品中真正想要什么？他们对质量有何期望？我们可以建立哪些流程和实践来确保质量？
处理所有这些事情可能相当棘手，尤其是在资源有限的情况下。我们如何在时间有限时控制范围？我们如何处理变更或避免项目范围失控？对客户而言，他们的需求可能不确定并随时间变化。对开发者而言，工作量可能随时间波动，不同开发者之间的生产力可能存在巨大差异，我们如何适应这种变化？这些问题始终萦绕在软件产品经理的脑海中。
在本专项课程中，我将教你有效的管理技术来处理这类问题。这些技术将帮助你协助团队生产出更好的软件。特别是，你将学习敏捷软件开发。
优秀产品的关键因素是人员和流程。你将了解更多关于敏捷实践与规划、需求、评审和回顾等主题。
作为开始，本介绍性课程包含两个模块。第一个模块强调软件产品管理的重要性和角色，并概述整个专项课程的目标、结构和期望。第二个模块介绍随着你深入学习专项课程，各门课程将涵盖的主题。
现在，想象你自己是一名出色的软件产品经理。你有一个靠窗的好位置。以下是关于工作任务的思考题，你可以选择多个答案：
- A. 与客户互动
- B. 管理和跟踪开发进度
- C. 与开发团队协作
- D. 在客户和开发团队之间传递信息
- E. 确保产品质量
作为一名软件产品经理，你将与许多不同的人互动，包括客户和开发团队。你还将负责管理和跟踪开发进度。确保产品按预期工作，并验证产品满足客户需求也是你的职责。然而，作为项目经理，你不需要充当客户和开发团队之间的信使，你希望鼓励他们直接频繁沟通。因此，正确答案是A、B、C和E。
接下来，让我们开始讨论如何打造更好的软件。软件产品经理需要理解多个视角来实现更好的软件。
第一个视角旨在为客户提供正确的软件产品。“正确的产品”意味着什么？这可能意味着许多方面的结合：它满足客户需求、易于学习和使用、不浪费客户时间，并且可能外观精美。基本上，客户对它感到满意。如果成立，我们说软件项目是已验证的。在本专项课程中，你将学习理解用户、如何获取他们的需求以及如何表达软件需求。
第二个视角旨在正确地构建软件产品。“正确地构建”意味着什么？这意味着软件符合特定设计，而该设计满足既定的需求。如果成立，我们说软件项目是已确认的。开发者可以进行评审和测试，以确保需求、设计和实现保持一致。此类活动旨在更早地发现缺陷，提高质量。他们希望避免客户在发布的产品中看到任何缺陷。在本专项课程中，你将学习改进软件质量的流程。
第三个视角旨在正确地管理产品项目。“正确地管理”意味着什么？这意味着确保其他视角得到满足。其理念是采用恰当的流程和文明实践来组织所有相关人员的工作。如果成立，我们说软件项目是被妥善管理的。此类活动促进沟通和反馈，使每个人都清楚下一步该做什么。在本专项课程中，你将学习敏捷实践、估算与规划以及监控。软件产品经理需要在这些活动中扮演核心角色。
总结一下，我刚刚解释了实现更好软件的三个视角：正确的产品、正确地构建和正确地管理。随着你深入学习本专项课程，你将更有信心了解并运用这些技术来创建更好的软件项目。这些技术包括促进沟通和反馈的流程，以更好地理解客户需求并组织开发团队的工作。
接下来，让我们谈谈软件产品管理的重要性。
021：3_01_1-1-2-为什么需要软件产品管理
概述
在本节课中，我们将通过一个虚构的、失败的软件项目故事，来理解为什么我们需要专业的软件产品管理。这个故事将揭示在没有有效管理的情况下，项目如何走向混乱与失败。
一个失败的项目故事
为了更好地理解为什么需要软件产品管理，让我们从一个关于软件产品管理如何彻底失败的故事开始。
你刚刚担任了软件产品经理的角色，领导自己的软件开发团队，任务是为一位新客户构建一个产品。
你的客户设想了一个革命性的新软件系统，每天要连接数十万终端用户。
项目截止日期定在六个月后。
你非常兴奋，这是一个展示你能力的大好机会。
你已经组建了团队，合同已经签署，一切准备就绪。接下来该做什么？
为了掌控局面，你认为最好的做法是明确规划出客户的需求。因此，你安排了一次会议，与客户面对面坐下，询问他们希望最终产品包含什么。
客户快速给出了一份非常有趣的想法清单，然后你就离开了。
你的开发人员热烈讨论着如何解决问题。他们各自选择了一些功能进行开发，然后分头行动。
项目似乎有了一个非常高效的开端。
时间快进到三个月后。
客户发邮件给你，要求亲自会面，演示到目前为止的成果。
突然间，你意识到，他们根本不清楚项目的实际进展。
你向开发团队询问进度更新，他们兴奋地告诉你各自正在做什么，并保证他们的部分会按时完成。
你告诉他们，客户想要一个演示。这时，气氛突然变成了恐慌。
他们说：“我们还没有集成任何功能。”，“我至少还需要一周才能完成我代码中的这部分。”，“我不知道我们有演示安排。”
现在，你也开始恐慌，因为你不得不告诉客户你没有任何可以演示的东西。
你的客户肯定会理解的，毕竟软件开发更像一门艺术，而不是一门精确的科学。
一半的项目资源已经消耗，事情似乎进展缓慢，你几乎看不清下周能完成什么，更不用说在演示日到来时能为客户提供什么了。
又两个月飞逝而过。你现在距离交付截止日期只有四周了。
团队完全处于恐慌模式。你的一位开发人员已经两周没来上班了，而他的代码成了整个系统的瓶颈。
你试图指派另一名团队成员来处理，但他们几乎看不懂原始的代码，认为不可能完成任何有意义的工作。
现在，你正在弥补从一开始就不存在的时间。距离产品的首次演示还有两周，你的团队承受着巨大的压力。
每个人都在通宵工作，编写和测试代码。为了节省时间，你把所有最佳编码实践都抛到了脑后，并且希望客户不会发现那几个你已无力让人花时间去修复的漏洞。
截止日期正在迅速逼近。你别无选择，只能请求客户延长一些时间。他们不会高兴的。
但他们除了同意，还有什么其他选择呢？你为自己争取到了一些额外时间。然而，他们仍然想看看你到目前为止的成果。
两周后，演示日。
在模糊的视线和咖啡因刺激的打字声中，你的团队拼凑出了一个粗糙的产品演示。每个人都很紧张，他们唯一的安慰是想着项目很快就要结束了。
直到客户开始彻底否定整个演示。客户说：“我从来没要过这个功能。”，“这个功能的目的是什么？”，“你为什么决定把这个元素放在这里？”，“我不能把这个展示给我的客户看。”
这令人心碎。他们的要求将带来更多的工作量。为什么他们一开始不能更具体一些？产品已经够晚了。你真的能再撑四个月吗？
现在，你没有按计划与家人共度美好的假期，而是被困在办公室里，把头撞在键盘上，希望有更好的方法。
解决方案：软件产品管理专业化课程
卡尔加里大学和阿尔伯塔大学可以提供帮助。大约只需一门大学课程的费用，你就可以访问整个按需提供的计算机科学专业化课程。
欢迎来到软件产品管理专业化课程，欢迎来到更好的软件世界。
在这个专业化课程中，我们的专家讲师团队将引导你完成所有步骤，释放你内心的项目管理“忍者”潜能。
你将学习如何从一开始就掌控你的项目，这样，像忍者一样，没有任何事情会悄悄接近你。
你将学习如何高效、协作地管理你的项目，这样，像忍者一样，团队中的每个人都知道正在发生什么。
你还将了解行业当前的最佳实践，这样，像忍者一样，你将成为自己技艺的大师。
软件产品管理的重要性
当今商业运行在软件之上。每家公司都有用于控制日常运营的内部应用程序，并且越来越多的公司通过网站和移动应用与外部客户建立联系。
为了成功实现商业目标，公司需要能干的软件项目管理专业人员，他们能够交付在21世纪运营所必需的数字资产。
欢迎来到软件产品管理的世界。这将是一段激动人心的旅程，我们希望你能在此过程中学到很多。我们非常期待你的加入。
总结
本节课中，我们一起学习了一个因缺乏有效管理而失败的软件项目案例。这个故事清晰地展示了，如果没有清晰的规划、持续的沟通、进度跟踪和风险管理，即使是最有才华的团队也可能走向失败。软件产品管理正是为了解决这些问题而存在，它通过系统化的方法，确保项目从开始到交付都处于可控状态，最终满足客户需求并实现商业目标。
022：软件产品经理的角色
概述
在本节课中，我们将要学习软件产品经理这一核心角色的具体职责、所需技能以及其重要性。我们将通过定义和行业专家的见解，来全面了解软件产品经理的工作内容。
在上一节中，我们探讨了软件产品管理的重要性。本节中，我们来看看担任软件产品经理这一角色具体意味着什么。
软件产品经理是一个核心的管理职位。这个角色类似于电影的制作人和导演，但没有红毯上的名气。你负责一个软件产品的成功。
但这个角色远不止是管理一个项目。它需要你真正理解产品，这意味着你必须像真实用户一样，知道产品能做什么以及它独特的优势。
你还必须了解商业案例，即该产品能为客户带来的价值，以及该软件将如何改变客户的业务格局。
优秀的软件产品经理精通多个领域。他们能用客户和开发人员各自的术语进行交流。他们能倾听并构想客户的愿景，与开发团队成员有效沟通，并激励团队取得最佳成果。他们还能管理客户期望，并且知道如何让开发团队发挥出最佳水平，他们关心自己的团队成员。
产品的成功也依赖于稳固的团队合作。程序员、测试员、用户体验设计师、图形艺术家必须协同工作。你的角色是赋能他们，让他们为你的项目贡献最佳努力。
软件产品管理是一个领导角色。让我们通过几个访谈，看看行业内的从业者如何看待这个角色。
以下是一些行业专家对软件产品经理角色的看法：
- “我的角色实际上是领导软件开发团队之一。但我确实将自己视为产品领导者，并且鼓励团队中的每个人都视自己为产品领导者。”
- “我的团队中有一位软件产品经理，我们紧密合作。产品经理负责将需求带给我，并帮助我理解客户的需求，然后我则与团队一起努力满足这些需求。”
- “我的很多工作是定义产品愿景、产品战略、产品路线图，以及为开发团队和体验设计团队制定规范。”
- “让我兴奋和感到挑战的是，让工程师、测试团队、文档团队明确无误地理解我们试图解决的问题是什么，这让我感到满足。”
- “产品经理与客户会面，他们获得一个想法，一个关于某物如何实现的愿景。他们向工程团队和相关利益相关者阐述这个愿景，然后他们看到它被实现为可工作的软件。看到它最终交付并看到它对客户及其现实产生的影响，这对产品经理来说是极大的满足。”
- “看到客户对成品的反应，阅读相关评论，看到它在商店里，这是非常有回报的。”
- “让团队围绕问题团结起来。如果人们来上班只是把它当作一份工作，他们不会创新。他们会做你告诉他们的事，然后回家。如果他们内化了你要解决的问题的使命，奇迹就会发生。”
- “模糊性是一个巨大的挑战。客户并不总是有能力准确解释他们到底想要什么。因此，我们倾向于采用许多不同的策略来发现他们想要什么，即使他们无法告诉我们。我们可能会观察客户，可能会坐下来看他们工作一段时间，以帮助他们克服表达的模糊性，找出他们实际需要什么。”
- “人们可能有10种不同的解决方式。所以对我来说，实验和快速迭代的方法确实是解决这个问题的关键。这意味着承认意见分歧和缺乏共同愿景，然后说，好吧，我们到底要做什么来解决它，以及我们如何确定这是否是正确的行动方案。”
- “作为领导者，首先，你需要能够做三件事：你需要能够用你的愿景激励他人，你需要能够组织需要完成的工作，你需要能够创新。”
- “坦率地说，如果你自己不能创新，你的工作就是雇佣能帮助你创新的人。他们需要能够倾听客户在说什么，并将其转化为需求，最终转化为工程团队可以构建和交付的规范。其次，你需要能够沟通。作为一个在组织内各个层面（向高管、工程团队、销售团队、营销团队）沟通或推销你愿景的人，你需要能够理解这些层面各自处于什么‘高度’，以及什么信息能引起他们的共鸣。”
- “建立真正良好关系的能力。进行战略性思考，同时在需要时也非常注重战术。这不是关于你。作为产品领导者，这从来不是关于你，而是关于客户的问题。你的工作，我的工作，是爱上客户的问题。”
软件产品经理的背景多种多样。以下是进入这个领域的几种常见路径：
- 有些人从业务端起步，意识到自己对软件有兴趣和技能，并且大致了解软件是如何构建的，然后他们会获得更多技术能力，并开始从那一侧参与进来。
- 有些人拥有计算机科学背景，从程序员做起，逐渐迁移到产品领导角色。
- 也有人看到拥有音乐学位的人成为了出色的产品领导者。
- 拥有计算机科学学位的人和拥有音乐学位的人的共同点，首先是领导力。如果你能激励人、组织人并能创新，你就能在产品管理方面做得好。
- 另一些人从工程侧进入，他们曾是优秀的工程师，但可能决定对愿景、规划方面以及协作而非实现更有热情。
- 很多产品经理是在工作中学习的。
对于有志成为产品经理的人，专家们给出了以下建议：
- “申请它。上网寻找，申请它。但要明白这一点：我们是来领导人的。你是来领导一个流程的。你是来解决客户问题的。如果你从自我认知的角度相信那就是你，那就申请它。”
- “他们应该了解他们的工程师。他们应该与工程师面临的问题、工程师能带来的机会保持高度一致。并且真正、真正专注于这种伙伴关系。”
- “我认为客户和客户研究至关重要。这是产品经理的基本技能，所以这是基本要求。除此之外，我认为要真正擅长与自己的团队以及利益相关者团队建立伙伴关系。”
- “对我来说，就是要痴迷于客户。立足于客户，非常非常了解他们，因为你的工作就是代表他们。如果你从这一点开始并且做得很好，如果你能深入理解你的客户，那么你某种程度上就已经领先了。”
正如你所看到的，软件产品经理的职位可以是一条充实的职业道路。优秀的产品经理能赢得客户和团队成员的尊重。出色的产品经理因其成功的产品交付记录而备受追捧。
无论你是想从开发者转向产品经理，还是你理解业务方面并希望更直接地参与塑造软件，或者也许你想寻求职业转变，更多地从事软件产品管理工作，无论你开始这条道路的原因是什么，本专业课程都将逐步指导你成为一名有能力、有信心的软件产品经理。
总结
本节课中，我们一起学习了软件产品经理的核心角色。我们了解到，这个角色是产品成功的中心，需要兼具对产品的深刻理解、商业洞察力以及卓越的领导与沟通能力。它要求从业者能够连接客户与开发团队，激励团队围绕共同目标努力，并最终交付能解决客户问题、创造商业价值的软件产品。这是一个充满挑战但也极具成就感的领导职位。
023：如何成为更高效的学习者 🧠
在本节中，我们将介绍一些在本专项课程中取得成功的具体方法，帮助你更有效地学习。这些建议旨在优化你的学习体验，确保你能够充分掌握课程内容。
概述
我们将提供五个关键建议，涵盖学习方法选择、互动参与、学术诚信、社区礼仪与个人信息安全。遵循这些建议，你将能更好地投入到课程学习中。
1. 采用适合你的学习方法
首先，我们建议你采用最适合自己的学习方法。我们提供了视频讲座和课程笔记两种形式，它们完整覆盖了课程内容，你可以选择对你最有效的方式。
以下是具体选择建议：
- 如果你通过阅读材料学习效果更好，请使用我们的课程笔记。
- 如果你更偏向视觉或听觉学习，观看视频讲座可能让你更成功。
- 视频讲座也配有字幕和文本稿可供阅读。因此，结合使用课程笔记和视频讲座或许对你最有效。
2. 积极提问
上一节我们介绍了如何选择学习材料，本节中我们来看看如何通过互动深化理解。我们建议你积极提问。如果你对课程材料有疑问，很可能其他人也有同样的问题。
请在论坛中发布你的问题。我们拥有一个强大的学习社区，其他学习者和课程助教都非常乐意为你提供帮助。
3. 提交自己的作业
我们的评估旨在帮助你练习课程中涉及的许多概念。但是，如果你不亲自完成作业，就无法获得评估所能提供的全部益处。
这不仅意味着错失学习机会，而且抄袭他人作业可能导致负面后果。根据Coursera荣誉准则，抄袭是指你在未给予适当署名的情况下，复制他人来源的文字、观点或任何其他材料。
适当署名应通过规范的引用方式给出。抄袭在学术环境中是不可接受的，并且严重违反了Coursera的荣誉准则。抄袭可能导致作业不及格、被移出课程，甚至被逐出Coursera社区。
4. 保持尊重态度
这是一个为全球众多学习者提供的学习环境。请尊重你的同学，并记住他们可能来自不同的文化、说不同的语言，并且背景与你不同。
你还需要注意自己书写的语气。在书面文字中准确解读语气并不总是容易的，因此某些内容可能会被误解或曲解。任何煽动性言论都是不被容忍的。
5. 保护个人数据
最后，为了成为更高效的学习者，我们建议你保护个人数据。我们鼓励你在课程中与其他学习者交流，但建议你不要在讨论论坛中分享你的个人住址、电话号码或电子邮件地址。
总结
本节课中我们一起学习了成为更高效学习者的五个核心方法：选择个性化学习方法、在论坛中积极提问、独立完成并提交作业以杜绝抄袭、在多元社区中保持尊重、以及谨慎保护个人数据。遵循这些建议，你将能更顺利、更有效地完成本课程的学习。
024：学术诚信与抄袭指南
在本节课中，我们将学习学术诚信的核心概念，特别是关于抄袭的定义、表现形式及其严重后果。理解并遵守这些规则对于顺利完成本专项课程以及未来的职业生涯都至关重要。
什么是抄袭？
根据课程荣誉守则的定义，抄袭是指在未注明出处的情况下，复制他人作品中的文字、观点或任何其他材料。
抄袭在任何学术环境中都是不可接受的，它严重违反了课程的荣誉守则。
抄袭的后果
以下是抄袭行为可能导致的后果：
- 作业被判不及格。
- 被移出课程。
- 甚至被 Coursera 学习社区除名。
抄袭的具体表现形式
上一节我们介绍了抄袭的定义和后果，本节中我们来看看哪些具体行为会被认定为抄袭。以下是几种常见的抄袭情况：
1. 复制粘贴他人文字
如果你复制粘贴了他人撰写的文字，这即被视为抄袭，除非你正确地注明了出处。即使你调整了语序或更改了部分词语，也必须为其原创工作署名。例如，在作业、测验或讨论区中复制粘贴其他学员或工作人员的文字，并将其作为自己的成果提交，是被禁止的。
2. 提交他人创建的文件
在本专项课程的一些课程中，你可能会被要求提交图片或图表作为作业。提交由其他学员创建或提交的图片，并声称是自己的作品，这被视为抄袭且被禁止。
3. 窃取观点创意
某些作业可能需要一些创造性。窃取他人的创意观点，即使提交的文档是由你自己创建的，也被视为抄袭。在学术或商业环境中，两个或更多人可能产生相同的想法是常见情况。为了保护自己不被指控为窃取（不仅在本课程中，在你的职业生涯中也同样重要），记录你的修订过程或以某种方式记录你的思考过程是一个好习惯。例如，你可以维护一个日志来记录每个想法或概念的起源时间。
总结与行动指南
本节课中我们一起学习了学术诚信中关于抄袭的核心内容。请确保在整个专项课程中提交你自己的原创作品。
如果你在课程中发现抄袭行为，请标记相关作业并提请课程工作人员注意。
025：专项课程概览 🧭
在本节课中，我们将要学习软件产品管理专项课程的整体结构与设计思路，了解后续的学习路径和课程安排。
以下是本专项课程的结构安排。
- 本专项课程共包含六门课程，从你正在观看的这门导论课程开始，并以一个顶点课程结束。
- 这门导论课程包含两个模块，你已完成第一个模块的大部分内容，它介绍了我们为何需要软件产品管理。
- 在下一个模块中，摩根·布拉德利将更详细地讲解软件产品经理必须具备的具体技能，并阐述这些技能为何对该职业至关重要。
完成本课程后，你将可以继续学习接下来的四门课程。这四门课程的结构与本课程略有不同。在这些课程中，你将首先从宏观视角了解概念，然后深入探讨使软件产品经理成为任何开发团队宝贵资产的技能与实践。
这四门课程中的每一门都比本课程内容更多，每门课程包含四个模块，每个模块结束时都有一个课程考试，该考试成绩将计入你的专项课程总成绩。
我们设计此专项课程的方式是，每门课程都建立在上一门课程所获知识的基础上。因此，我们鼓励你从头开始，按顺序完成所有课程。然而，我们的“软件流程”课程和“客户需求与软件需求”课程经过特别设计，你可以按任意顺序学习它们。
鉴于我们来自一所加拿大大学，我想与你分享我们文化遗产的一部分。你或许能认出这张来自2010年温哥华冬奥会的因纽特石堆图像。因纽特石堆是北极地区因纽特人用来标记路径、类似人形的石制地标。因纽特石堆的传统寓意是：“你正走在正确的道路上。”
这不仅是对你即将在本课程中开启的旅程的一个绝佳隐喻，也代表了我们构建专项课程的方式。我们希望你将专项课程视为一个因纽特石堆。
这门导论课程就像是构建我们这座石堆的地基。组织软件生产活动很重要，弄清楚客户需求也同样关键。我们的“软件流程”和“软件需求”课程就像是石堆的基座，它们将支撑起其余所有部分。在此之上，项目需要适应性规划工作和定期审查进度，因此我们石堆结构接下来的部分将是躯干和手臂，即“软件规划”和“项目评审”课程。没有基座的石堆只是一堆石头；同样，如果只学习项目规划与评审，而不从根本上理解流程和需求的重要性，将形成一种追逐移动目标、产生大量忙碌却收效甚微的管理风格。
最后，每个因纽特石堆都需要一个头部。在本专项课程中，拼图的最后一块将是专项顶点课程。在这里，你将应用在先前课程中学到的所有概念。顶点课程是一个为期六周的项目，你将为一个模拟的软件开发团队进行评估和决策，旨在为一位要求苛刻的客户创造产品。要参加顶点课程，你需要完成所有先修课程。
完成所有先修课程和顶点课程后，你将获得软件产品管理证书。此证书是你完成所有认证所需工作的证明。
每个模块的工作量预计为两到四小时，每个模块的内容大约相当于一周的学习量。虽然工作量不大，但这并不意味着本课程内容不多。这个估算是基于我们为你准备的视频时长，以及所有阅读材料和评估内容。我们将发布额外的阅读资源供你参考。我们建议你尽可能多地查阅这些资料，以便充分利用你与我们共度的学习时光。你在这门课程上投入越多，收获就越大。
我们在这里为你提供一切可能的资源，使你能够轻松地从本专项课程中获得最大收益。此外，课程设有讨论区，你可以在其中写下关于课程的任何问题或评论，请善加利用。你的同学以及课程助教都将非常乐意帮助你澄清任何不太明白的地方。
在整个课程学习过程中，你将需要完成定期测验。这些测验旨在帮助你保持专注和进度，并让你有机会检查刚刚学到的知识。与课程期末考试不同，这些测验不计入你的专项课程最终成绩。
在之前的课程中，我们已经简单讨论了我们希望从本专项课程中获得什么。值得重申的是，我们希望让你对自己的软件产品管理技能充满信心。我们将为你提供掌握这些技能所需的所有资源。但如果你有任何不清楚的地方，请不要犹豫，在课程讨论区提出你的问题。
以下是关于软件项目的一个选择题。
A. 软件产品的功能必须在开发开始前全部确定，且一旦开发启动就不得更改。
B. 客户只有在开发完全结束后才能看到软件产品。
C. 项目管理计划一旦确定，就应坚持执行，不再更改。
D. 敏捷软件开发类似于黑客行为，不需要规划。
以上答案均不正确。对于软件产品，变化是持续发生的，以应对新的需求和机遇，因此答案A和C是错误的。客户应在开发过程中参与并提供反馈，而不仅仅是在结束时，因此答案B是错误的。最后，敏捷软件开发是一套有规划的、遵循特定规则的严谨实践，因此答案D也是错误的。
接下来，让我们开始我们的第一个作业。这是一个向班级介绍自己并反思目前所学内容的好机会。请前往课程讨论区，写一段简短的自我介绍。告诉同学们你的情况、背景以及学习本专项课程的原因。也请阅读一些同学的介绍，这有助于建立一个强大的学习社区。
我们的第一个模块到此结束。当你回来时，我们将深入探讨软件产品管理的更多具体内容，以及我们为何首先需要它。下次见。
026：项目成功与敏捷的重要性
概述
在本节课中，我们将探讨如何定义软件项目的成功，并理解为何采用敏捷实践是实现项目成功的关键因素。我们将分析衡量成功的不同标准，并揭示敏捷方法如何帮助团队达成这些目标。
项目成功的定义
上一节我们介绍了软件产品管理的概览，本节中我们来看看如何衡量一个项目的成功。软件产品管理专业人士通常使用进度、预算和用户需求作为定义成功的基准。
以下是衡量项目成功的三个常见因素：
- 按时交付：项目在预定时间表内完成。
- 按预算交付：项目支出未超过批准的预算。
- 满足需求：最终产品符合或超出了既定的功能与规格要求。
2013年由Scott Ammbler and Associates进行的一项调查询问了参与者如何定义成功。结果显示：
- 58%的受访者认为“按时交付”是重要因素。
- 36%的受访者认为“按预算交付”是重要因素。
- 仅有14%的受访者认为“按规格构建”是交付成功项目的必要条件。
- 只有8%的受访者认为一个成功的项目需要同时满足按时、按预算、按规格这三个条件。
值得注意的是，30%的参与者认为“按时”是决定项目成功的唯一因素，而仅有1%的人认为“满足规格”是唯一重要因素。你可以在课程资源中找到这项研究的链接。
其他成功指标
除了传统的铁三角（进度、预算、范围），项目成功还可以通过其他维度来衡量。例如：
- 开发者满意度：开发团队的工作体验和士气。
- 发布后缺陷数量：产品发布后发现的错误数量。
- 所需支持：发布后需要的客户支持量。
- 产品客户评分：用户对产品的评价。
- 产生的收入：产品带来的财务收益。
- 客户满意度：最终用户或客户的满意程度。
无论你选择如何衡量成功，敏捷实践都能帮助你实现它。
影响项目成功的关键因素
在讨论了如何衡量成功之后，我们来思考一下：对于项目的成功，你认为哪个因素最为关键？
- A. 一个好创意
- B. 一支有才华的开发团队
- C. 一个商业模式
- D. 资金
- E. 时机
根据多位初创公司创始人Bill Gross的TED演讲，产品发布的时机是商业成功最重要的因素。一个好创意需要有需要它的客户，而时机决定了市场是否准备就绪。因此，E（时机） 是正确答案。推荐你在课程资源中观看这个TED演讲。
为何采用敏捷实践
现在我们已经了解了如何定义和衡量成功，接下来我们看看敏捷如何促成这些成功。敏捷实践为开发带来专注力，确保项目以稳定、可控和高效的节奏推进。
这能防止程序员被项目压垮，从而造就快乐且高效的开发团队。敏捷实践还鼓励频繁且一致的测试，这有助于减少缺陷。
更重要的是，敏捷实践鼓励与客户持续沟通。让客户全程参与项目能为他们提供透明度，确保客户最终得到的正是他们要求的，甚至是超出他们想象的成果。开发团队的目标是让客户满意，即使是最出色的产品，如果不符合客户的需求和期望，也是失败的。
请记住，成功不是终点，尤其在软件开发中，失败也未必是致命的。美国实业家亨利·福特说过：“失败只是一个机会，让你能更明智地重新开始。”软件开发的核心就是迭代与演进。一周的成功或失败并不能保证下一周的结果相同。软件在不断变化，因此我们必须具备适应性。
敏捷的广泛影响与价值
或许你现在能看出，项目成功更像是在一条道路上行走，而非停留在某个目的地。敏捷实践将影响整个开发过程，最终创造出更好的软件、更快乐的开发者和更满意的客户。
当你学习敏捷并对其实践建立信心时，你正在培养许多大型科技公司所需求的技能。例如，Adobe、Amazon、Microsoft和Yahoo等公司都采用了一种流行的敏捷方法论——Scrum。我将在关于软件过程和敏捷实践的课程中带你深入了解Scrum的实践。
总结
本节课中，我们一起学习了如何从多个维度定义和衡量软件项目的成功，并深入探讨了敏捷实践为何是实现这些成功目标的关键。我们了解到，敏捷通过促进稳定节奏、持续测试和客户沟通，不仅能提升产品质量和团队效率，还能直接满足客户需求，从而在动态的软件开发环境中持续交付价值。下一课，我们将更深入地探讨敏捷的核心原则。
软件产品管理：1：敏捷宣言详解 🚀
在本节课中，我们将学习敏捷软件开发的核心思想——敏捷宣言。我们将了解其诞生的背景、四大核心价值，并通过一个案例来理解如何在实际项目中应用这些价值。
欢迎来到敏捷基础实践的探索。我相信你将看到这些指导原则如何提升你项目的成功率。
之前的内容已经表明，使用敏捷实践优于使用杂乱无章的管理方法。现在你可能会问，到底什么是敏捷？
敏捷宣言诞生于17位软件专家在一次滑雪胜地的聚会，他们旨在找到更好的方法来管理优秀软件的生产过程。由于每个重要团体都需要一个酷炫的名字，这些创始人后来被称为“敏捷联盟”。他们确立了关于软件开发中最重要事项的四大核心价值声明。
为了进一步阐述这些核心价值，联盟还达成了12条支持性原则。接下来，我们看看他们提出了什么。
以下是敏捷宣言的四大核心价值：
- 个体和互动 高于 流程和工具。
- 可工作的软件 高于 详尽的文档。
- 客户合作 高于 合同谈判。
- 响应变化 高于 遵循计划。
这意味着，虽然右侧项仍有价值，但我们更重视左侧项。当敏捷联盟说他们更重视左侧项时，并非建议你忽略流程、工具、文档、合同或计划。他们是在建议，左侧项是更值得关注的重点。
为了理解这些价值如何应用，让我们看一个案例。
保拉一直在为“真北航空系统”管理一个新数据库系统的开发。每两周，她都会邀请客户参加周五下午的会议，开发团队在会上演示最新的产品原型。
本周的会议促使客户和开发团队讨论了一个新的用户界面功能，该功能将允许用户轻松地向数据库输入信息。保拉记录了新需求，并提醒自己安排与法律团队及客户的会议。签署修订后的合同是必要的，以便团队获得新功能的书面规范。
请判断保拉的哪些做法符合敏捷宣言的价值观：
A. 定期演示新原型。
B. 开发团队与客户有面对面交流时间。
C. 随着新需求的识别，产品不断演进。
D. 更新合同以明确新功能。
答案A符合“交付可工作软件”的敏捷价值。答案B符合“客户合作”和“个体与互动”的敏捷价值。答案C符合“响应变化”的敏捷价值。
保拉的做法不符合“客户合作高于合同谈判”的敏捷价值。尽管她鼓励与客户频繁、开放的沟通，但开发团队仍需通过修订合同来获知已达成一致的功能规范。
上一节我们通过案例分析了敏捷价值的应用，现在让我们详细解读宣言中的四大核心价值。
价值一：个体和互动高于流程和工具。
你的开发人员和客户在协作关系中会更高效、更有成效。作为产品经理，你不是信使，你需要促进想要产品的人与生产产品的人之间的沟通。
价值二：可工作的软件高于详尽的文档。
回顾宣言，它指出右侧项仍有价值。因此，文档仍应在整个项目中持续创建。但当面临艰难抉择时，一段可工作的软件远比一份描述软件应做什么的文档更有价值。
价值三：客户合作高于合同谈判。
这意味着你需要与客户培养一种积极的关系，更关注他们想要什么，而不是过分拘泥于合同条款。客户是设计的中心，确保他们的愿景得以实现至关重要。
价值四：响应变化高于遵循计划。
软件在不断变化，以易于响应变化的方式来开发软件非常重要。在后续的基础课程中，你将学到许多敏捷实践，它们将使你的项目更能适应变化。
现在你可能会想，在你的项目中实施其中一项或多项价值可能不切实际。这没关系，敏捷是灵活的。重要的是，你去实施那些确实行之有效的价值。
在本节课中，我们一起学习了敏捷宣言的起源、其四大核心价值（个体与互动 > 流程与工具、可工作软件 > 详尽文档、客户合作 > 合同谈判、响应变化 > 遵循计划），并通过案例分析加深了对这些价值观在实际场景中应用的理解。记住，敏捷的核心在于灵活性和以人为本，选择适合你团队和项目的实践才是关键。
028：交付可工作的软件
在本节中，我们将深入探讨敏捷宣言的12条原则，特别是聚焦于“交付可工作的软件”这一核心理念。我们将了解为何频繁交付有价值的软件是满足客户的关键，以及如何将其作为衡量项目进展的主要标准。
上一节我们介绍了敏捷的价值观，本节中我们来看看支撑这些价值观的具体原则。敏捷宣言的12条原则对价值观进行了详细阐述，提供了更具体的指导方针。敏捷方法论则通过应用各种工具和实践来确保这些原则得以实现。
现在，让我们逐一审视这12条原则。为了便于理解，我将这些原则分为了三个类别：交付可工作的软件、灵活设计与适应变化以及协作沟通与组织。接下来，让我们一起探讨第一类原则。
聚焦于交付可工作的软件
“可工作的软件”是敏捷方法的一个关键方面。当团队专注于交付可工作的软件时，它能有效驱动开发进程。即使在开发的早期阶段，每一次可工作软件的交付都成为一个可运行的原型，并将在下一轮开发中得到改进。一段可工作的软件能让客户满意，因为他们可以在整个过程中看到其产品的演示。
以下是与此类别相关的几条原则：
原则一：我们最重要的目标，是通过尽早和持续地交付有价值的软件来满足客户。
在这条原则中，“有价值的”一词至关重要。你需要询问客户他们认为什么是有价值的。客户最看重的功能应成为你开发团队的最高优先级。
原则二：欢迎不断变化的需求，即使是在开发后期。敏捷过程利用变化为客户创造竞争优势。
这条原则是关于交付频率的：频繁地交付可工作的软件，周期从几周到几个月不等，且倾向于较短的周期。可以这样思考：你的软件交付越频繁，客户就有越多的机会对开发提供反馈。
原则三：可工作的软件是衡量进展的主要标准。
既然你的团队将专注于交付可工作的软件，那么你的进展就应该以此为标准来衡量。当我提到“可工作的软件”时，它意味着一种完成度。在敏捷中，一个功能只有在所有代码都已编写、测试并归档后，才能被视为完成。你需要确保你的开发团队是在完成功能，而不是开了很多头，但实际完成的却很少。
构建易于变更的软件产品
我已经提到过，软件是不断变化的，这是你必须准备好面对的事情。拥有一个对变更友好的项目，意味着你的项目能够轻松适应变化。
那么，你认为以下哪些是使你的软件产品更易于变更的好方法？（可选多项）
- A. 频繁的客户沟通
- B. 未注释的源代码
- C. 持续审查和改进你的项目
- D. 持续更新的、已排定优先级的特性列表
- E. 对变更持开放态度的开发团队
以上所有选项都是使你的项目更易于变更的方法。我们将在整个专项课程中更详细地回顾这些实践。
本节课中，我们一起学习了敏捷原则中关于“交付可工作的软件”的核心部分。我们明确了以满足客户为最高优先级，通过频繁交付有价值的软件来实现，并将可工作的软件作为衡量进度的首要指标。同时，我们也初步了解了构建一个能灵活适应变化的项目环境所需的一些关键实践。下一节，我们将继续探讨关于灵活设计与适应变化的敏捷原则。
029：敏捷原则之灵活设计篇
在本节课中，我们将学习敏捷宣言中关于灵活设计与适应变化的核心原则。我们将探讨如何通过拥抱变化、追求技术卓越、保持可持续的开发节奏以及崇尚简洁，来构建更具韧性和响应力的软件产品。
上一节我们介绍了敏捷宣言中以人为本的原则，本节中我们来看看另一组核心原则，它们聚焦于灵活的设计与对变化的适应。
正如之前所述，变化在软件开发中是不可避免的。你需要以这样一种方式规划项目：变化不会对项目造成损害。使产品更能响应变化的一个好方法是拥有灵活的设计和可适应的流程。
我将从第四个原则开始讲解这一类别，它关乎需求的变化。
原则四：欢迎变化的需求，即使在开发后期。敏捷流程善于利用变化为客户创造竞争优势。
变化最终会创造出更好的产品，它能满足你的客户，并为你的产品带来竞争优势。
接下来这个原则阐述了良好的开发实践。
原则五：持续关注技术卓越和良好设计能增强敏捷性。
拥有可读性强、简洁的代码和更灵活的设计，将使变更更容易实施。良好的设计可以让你了解哪些组件是相互依赖的。
我们将要探讨的下一个原则是关于可持续开发的。
原则六：敏捷流程倡导可持续开发。发起者、开发者和用户应该能够长期保持稳定的节奏。
如果你曾在软件开发领域工作过，你可能对那种不幸的开发冲刺很熟悉——为了在截止日期前完成任务。这种不稳定的节奏会导致开发团队精疲力竭，并对项目成功产生负面影响。
我们已经讲到了一半，让我们继续前进，谈谈第七个原则，它关乎简洁。
原则七：简洁——即最大化未完成工作量的艺术——是根本的。
这并不意味着敏捷就是交付更少的东西，而是意味着敏捷专注于交付本质的东西，减少不必要的工作。这意味着编写更少的代码和文档，专注于交付一个尽可能简洁的高影响力产品。
以下是关于“简洁”原则的一个思考案例：
萨姆是你开发团队中的一名开发人员。他痴迷于敏捷的简洁概念。他编写的软件代码非常精简，只完成它应该做的工作，没有任何不必要或复杂的代码。他也不添加注释来记录他的代码。萨姆认为团队应该只开发使产品运行所必需的功能，而不应该把时间浪费在客户认为能为产品增加价值、但他认为无用的花哨功能上。他拒绝参与编写详尽的文档，但会写下他如何开发该功能的笔记、任何关键要点以及给最终用户的简短培训文档。
你认为他的哪些做法（如果有的话）真正遵循了敏捷宣言中的简洁概念？
以下是选项：
A. 满足所需功能的最小化代码。
B. 代码中没有注释。
C. 只开发基本功能。
D. 必要的文档胜过详尽的文档。
萨姆对简洁的看法并不完全符合宣言的建议。但在某些方面他是对的。
- 最小化的代码是专注于简洁的好方法。
- 代码中的注释有助于解释特定解决方案的原理。使用注释可以使代码更容易与其他开发人员共享，这是为项目添加少量但有效文档的简便方法。
- 此外，团队开发功能不应基于他们自己对重要性的标准，而应基于什么能满足客户。如果某些功能能为产品增加价值并且是客户需要的，那么就应该实施。作为产品经理，你可能需要解释为什么某些功能能增加价值。
- 然而，他的文档风格是将必要信息传递给正确人员的好方法。可能不需要全面的文档，简短简洁的文档可能会鼓励人们真正去阅读它。
因此，A和D是正确答案。
本节课中，我们一起学习了敏捷宣言中关于灵活设计的核心原则。我们了解到，拥抱变化、追求技术卓越、保持可持续的开发节奏以及崇尚简洁，是构建能够适应变化、持续交付价值的软件产品的关键。这些原则共同指导我们，在复杂多变的开发环境中，如何保持产品的韧性和团队的活力。
030：12_04_1-2-2c-协作沟通与组织
概述
在本节课程中，我们将学习协作沟通与组织相关的敏捷原则。这些原则对于任何希望开发优秀软件的团队都至关重要，它们指导我们如何构建团队、促进沟通并持续改进。
协作沟通与组织原则
团队的组织方式可以促进更好的沟通，并推动优秀的软件开发。让我们从第八条原则开始，它关乎信任。
原则八：信任与赋能
围绕积极主动的个体构建项目。为他们提供所需的环境和支持，并信任他们能够完成工作。
这意味着，作为产品经理，有时需要退后一步。这或许很难做到，但重要的是更多地扮演团队促进者的角色。乔治·S·巴顿将军曾说过：“告诉人们去哪里，但不要告诉他们怎么去，你会对结果感到惊讶。”
原则九：自组织团队
最好的架构、需求和设计出自自组织团队。
敏捷鼓励团队自组织。这意味着团队共同决定如何组织项目，包括分配任务和选择使用的工具等事项。
原则十：紧密协作
业务人员和开发人员必须在整个项目期间每天一起工作。
再次强调，作为产品经理，你将扮演促进者的角色，而绝非双方之间的传话筒。
原则十一：面对面沟通
向开发团队及团队内部传递信息的最有效、最高效的方法是面对面交谈。
能够直接与项目团队成员交谈可以减少误解的机会，并提高工作推进的速度。如果团队具备同地办公的条件，请充分利用这一点，进行频繁而简短的面对面会议。当团队分布在全球时，使用视频会议等沟通工具。虽然效果不如面对面沟通，但尽力而为非常重要。
原则十二：定期反思与调整
团队定期反思如何能变得更高效，并相应地调整自身行为。
你的流程与你正在创造的产品非常相似，你需要测试你的流程，审查它们并进行改进。敏捷培训师兼作者亨德里克·克努伯格说过：“重要的不是你的流程，重要的是你改进流程的流程。”流程与编写代码非常相似，一个首次就完美的流程相当于一个首次编译就没有错误的程序，这是不可能的。
自组织团队实践案例
你在一家为航空公司开发应用程序的全球性公司工作。你最新的项目是管理一个取代航空公司电视屏幕的娱乐应用程序的开发。你的开发团队在开发和敏捷实践方面都经验丰富，他们实现了团队自组织。
那么，这个自组织团队实际上是什么样子的？以下是可选的描述，请选出所有适用的选项：
- A. 产品经理无事可做。
- B. 他们商定了要遵循的某些实践。
- C. 他们决定在完成任务时自行分配任务。
- D. 他们任命了一位负责团队的领导者。
B和C是团队实现自组织的绝佳方式，也是正确答案。自组织团队旨在鼓励沟通、团队合作、高效开发、积极性和相互尊重。任命某人为领导者并不能让每个人都处于同等的尊重水平，也不鼓励平等的责任。自组织团队也并不意味着你无事可做；你需要在团队选择的实践中管理和指导他们。
总结与应用
现在你已经了解了敏捷宣言的原则，你可能会想，我已经给出了所有这些原则，但没有提供应用它们的方法。在本专业课程中，你将学习到的大多数概念和实践都将与一条或多条敏捷原则相关。到本课程结束时，你将掌握工具和知识，能够自信地将这些原则应用到你的项目中。
如果你能重温敏捷宣言，并将后续课程中学到的内容与本课介绍的原则和核心价值观联系起来，你将能从本课程中获得最大收益。如果你有兴趣了解更多关于敏捷宣言的信息，可以访问 Agilemanifesto.org。
我曾作为开发者和产品经理参与过许多团队，经历过使用和不使用敏捷实践的开发过程。我的一个非敏捷产品在交付时，只有三分之二的功能真正完成。请注意，我并非全盘否定非敏捷方式，我也经历过偏离轨道的敏捷项目。区别在于，我们很早就注意到敏捷项目正在失败，并且我们能够挽救它。而对于那个非敏捷产品，直到我们交付时，我才知道项目失败了。
敏捷原则是否在你的某次经历中让你受益？你是否参与过一个本可以采用敏捷方式的项目？欢迎在课程讨论中分享你的经验。请记住，这些经验不一定特定于软件开发，我意识到我们的学习者来自许多不同的行业。让我们看看这些行业如何相互关联，以及敏捷如何应用于软件之外的许多事物。
现在你了解了敏捷原则，你需要将它们应用到具体事务中。每一个优秀的项目都有一个流程。在下一课中，你将学习为什么流程对产品管理和开发如此重要。我们下节课见。
031：为什么需要流程
在本节中，我们将探讨为什么在软件开发中需要一个明确的流程。我们将了解流程的定义、其核心阶段，以及它如何帮助团队避免混乱、提高效率并最终交付成功的产品。
我们已经讨论了项目成功的要素，并介绍了敏捷宣言。你可能在思考如何将敏捷的价值观和原则实际应用到项目中。一个定义良好的流程是应用这些原则的良好基础。流程将人员的工作组织成不同的阶段或步骤，以开发软件产品。
当你想到软件开发时，脑海中会浮现出一些阶段。以下是几个例子：
- 项目规划
- 编写代码
- 测试软件
- 产品维护
这些只是一些例子，但组织开发流程的方式可以有很多种。在后续的“软件流程与敏捷实践”课程中，你将探索几种组织软件开发流程的模型。
为了帮助你理解“阶段”的概念，让我们思考一个简单的问题：如果你要为制作披萨创建一个流程，你认为阶段可能是什么？
A. 面饼、酱料、奶酪、意大利辣香肠。
B. 规划、准备、组装、烹饪。
C. 拨打、订购、吃、剩菜。
D. 制作、烘烤、吃、吃剩菜。
A不正确，因为这些更像是原料而非可执行的阶段。C可能正确，但前提是我们创建的是“订购”披萨的流程，而不是“制作”披萨的流程。D不正确，因为它包含的是低层次的具体动作，而非高层次阶段。因此，B是正确答案，因为它包含了规划、准备、组装和烹饪这些高层次阶段。
尽管在产品生命周期中组织工作的流程多种多样，但它们通常共享“阶段”这一高层概念。常见的阶段包括：
- 规格说明：构思产品创意的阶段。当你能明确软件将要做什么时，就完成了规格说明阶段。
- 设计与实现：找出构建软件的最佳方式，以便开始有效的设计和编码。
- 验证与确认：测试软件中的缺陷，并确保系统交付了客户所需的功能。
流程对于组织开发、确保工作按逻辑顺序完成是必要的。它们还能确保步骤不被遗漏或忽视。当你不知从何开始时，软件开发会令人望而生畏。流程也明确了项目应该从哪里开始。
现在，让我们通过一个练习来巩固对阶段的理解。假设你是一个开发新视频游戏项目的产品经理，你的团队负责角色选择界面。团队需要完成的任务包括：
- 编写选择角色的测试
- 规划角色的外观
- 编写多人选择功能的源代码
- 执行更改角色颜色的测试
那么，哪些任务属于“验证与确认”阶段？
A. 编写选择角色的测试
B. 规划角色的外观
C. 编写多人选择功能的源代码
D. 执行更改角色颜色的测试
编写选择角色的测试和执行更改角色颜色的测试都有助于评估产品是否按预期工作。因此，答案A和D属于验证与确认阶段。
接下来，让我们思考没有流程的软件开发会是什么样子。想象你有一个很棒的应用创意，如果你仅仅凭想象就开始编码，这就像坐在键盘前，指望一部伟大的小说能从你的指尖自动打出来。这通常被称为“临时性”开发。你按时生产出好产品的几率非常渺茫，甚至可能是不可能的。
临时性开发会带来许多问题，一个主要担忧是糟糕的设计。如果你的编程只是随着脑中冒出的想法进行，你可能会花费大量时间开发构思不佳的功能，结果却在开发中途改变主意。时间是宝贵的，而推倒重来的代价是高昂的。
相反，通过一个设计良好且人人遵循的流程，你将能够监控项目的所有方面。这种可见性将帮助你有效地设定工作预期、管理风险、避免浪费资源，并交付一个经过深思熟虑的产品。当开发者理解流程时，他们也能更好地在开发早期发现缺陷或糟糕的设计。朝着共同目标协同工作将节省时间和金钱。
一个定义明确的软件流程还为开发团队中的每个人规定了角色和职责。采用软件流程似乎是产品开发的自然步骤，甚至流程会自然出现也是直觉使然，但遵循一个定义好的流程模型能让每个人都知道该期待什么。随着你在专业课程中的深入，你将熟悉许多行业标准的软件流程模型。一个稳健的软件开发流程是你构建优秀软件的发射台。
所有开发流程的第一步都是理解你要创造什么，也就是我们下一课的主题：初始软件需求是什么。
在本节中，我们一起学习了软件开发流程的重要性。我们明确了流程是将工作组织成阶段（如规格说明、设计与实现、验证与确认）的基础，它能防止临时性开发的混乱，提高团队协作效率，并确保产品按计划交付。记住，一个好的流程是项目成功的起点。
032：为什么需要需求？📋
在本节课中，我们将探讨在软件项目中，需求为何如此重要。我们将从几个主要原因入手，并举例说明当忽视需求时会发生什么。
概述
需求是对客户需求的一系列具体描述。客户是最初希望构建软件产品的人或群体。需求与流程相结合，是任何成功软件项目的支柱。
为什么需要需求？
以下是需求至关重要的几个关键原因。
1. 定义产品功能
需求决定了软件产品的功能。例如，一个优秀社交网络应用的需求列表可能包括：
- 用户可以在其数据中存储用户档案。
- 向其他用户发送消息。
- 查看其他用户的档案。
- 创建状态更新。
- 查看其他用户的状态更新。
这个简单的例子表明，需求直接生成了软件产品的特性。
2. 消除歧义，避免混淆
模糊的请求会导致开发人员产生巨大困惑。例如，一个看似简单的请求“用户可以通过应用相互交谈”应该如何转化为需求？是指发送语音便签、文本消息还是其他方式？这种模糊性需要通过获取更多细节来澄清，从而精确地确定需求。
在软件开发中，避免混淆至关重要，这始于知道如何正确地获取和表达需求。
3. 提前发现潜在错误
通过花时间细化需求，你可以在产品构建之前就发现潜在的错误。澄清想法能使开发工作变得专注且高效。
让我们看一个例子。假设一位开发人员开始开发这个社交网络应用，并遇到了这个需求：“用户必须能够以访客身份发送消息。”开发人员可能会据此设计一个系统，让用户可以选择登录自己的账户或使用一个访客账户。
一个单一的访客账户满足了需求，但是当许多不同的用户都能访问同一个访客账户时，是否会产生意想不到的后果？根据开发人员对需求的理解，这个访客账户变成了一个大账户，任何人都可以在其中相互发送消息并看到对话记录。
这个不幸的设计错误是需求定义不清的结果。想象一下，构建一个考虑不周的功能会投入多少时间和精力——实现成本高昂，修复成本更高。
知识测验
现在，我们来看看你是否能找出需求在软件开发中重要的关键原因。
情景：你正在与客户合作，为软件产品获取一套需求。客户拿出一张餐巾纸，上面勾勒了一个具有几个概要功能的应用草图。他说：“这就是我们想要的产品。”
问题：如果你接受这份文档作为最终需求集，而不是与客户一起细化它们，以下哪些是你的项目的潜在风险？
A. 产品实现错误可能直到软件编码完成并测试后才会显现。
B. 产品可能无法满足最终用户。
C. 客户对产品的外观和感觉有过多输入。
D. 相关人员缺乏协作，士气下降。
答案：A、B 和 D。
客户对产品外观和感觉有过多输入并不是产品风险。实际上，客户在过程中参与越多，事情往往进展越顺利。但这并不意味着你应该让客户完全控制开发，你们应该协作以创造最佳产品。协作也有助于提高士气，快乐的团队往往工作效率更高。
总结
本节课我们一起学习了需求在软件项目管理中的核心重要性。需求是定义产品功能、消除开发歧义以及在早期发现潜在设计错误的基础。忽视或接受模糊的需求会导致实现错误、产品无法满足用户以及团队协作问题。
要了解更多关于如何确保充分利用需求的知识，建议你学习本专项课程中的“客户需求与软件需求”课程。
在下一节课中，Morgan 将讨论为什么需要花时间规划你的项目。
感谢观看。
033：为什么需要规划？🚀
在本节课中，我们将要学习软件产品管理中规划环节的重要性。我们将探讨规划如何帮助我们将未来目标转化为当前可执行的行动，以及它如何通过风险管理来提高项目成功率。
艾伦·拉肯是一位以个人时间管理书籍而闻名的作家。他说，规划是将未来带入当下，以便你现在就能为此采取行动。
一个计划指明了现在可以做什么，它能推动你朝着未来的目标前进。
规划涉及使用流程和需求来开始组织任务和排期。创建任务和排期需要确定谁应该完成工作，并估算这项工作需要多长时间。
需求编写得越差，准确的时间估算就越困难。需求越具体，估算完成工作所需的时间就越清晰。
那么，当你的排期基于糟糕的时间估算时会发生什么？
你的整个项目时间线将变得无法实现。
想象一下，你高估了工作量。你向客户提供了基于时间的估算和不准确的时间线。你夸大的项目计划会让客户认为你不理解这个项目，他们可能会将业务转向别处。
或者想象一下，你低估了工作量，并向客户承诺他们的项目将在特定日期完成。在不产生额外费用的情况下，最可能的结果是你无法按承诺交付。
估算对于确保你不会对客户过度承诺也很重要。
如果你的所有估算都过于乐观，你会错误地认为自己可以为产品添加许多很酷的额外功能。过度承诺最初会让客户感到高兴，但当交付时间到来时，客户会感到失望。即使产品本身很棒，它仍然没有达到你承诺的水平。
正如我们刚才所讨论的，估算和排期是良好规划实践的重要组成部分。拥有良好的估算可以降低项目风险。降低风险和提前规划都是风险管理的一部分。
现在，假设你正在为一家本地初创公司工作，你已经完成了大部分规划，现在需要为开发任务进行时间估算。
你认为谁负责创建时间估算？请选择所有适用的选项。
A. 开发人员
B. 你，软件产品经理
C. 客户
D. CEO
开发的时间估算由开发人员和软件产品经理共同决定。开发人员最清楚开发功能需要多长时间，但作为产品经理，你也可以提供另一种意见。因此，A和B是最正确的答案。客户和CEO可以确定目标日期，但他们通常不参与时间估算。
风险管理是规划带来的最大好处。请记住艾伦·拉肯的话：规划是将未来带入当下，以便你现在就能为此采取行动。如果你能预测未来的风险，并在当下采取措施来减轻它们，那么你的项目将有更高的成功几率。
以下是一些我们可以在规划阶段管理的风险示例：
以下是规划阶段可以管理的一些风险示例：
- 开发团队职责：你可以制定计划，明确需要完成什么以及由谁来完成。这将减少关于职责归属的误解。协调一致的工作有助于高效开发，并有助于建立稳定的开发节奏。这是敏捷宣言中提到的一个原则。
- 软件发布缺陷：有效的规划可以预留足够的测试时间。这将减少发布产品中的缺陷，并为修复发现的重大缺陷留出时间。
- 错过截止日期和/或超出预算：规划可以使开发保持在正轨上，从而减少资源浪费。这降低了项目延期和/或超支的风险。
现在，假设你作为一名产品经理，正在负责一个为下一次太空任务开发通信应用程序的项目。这个产品必须按预期工作，因此你花了大量时间与开发团队一起识别风险，并列出了一份长长的潜在风险清单。
既然潜在风险已经确定，你认为下一步应该做什么？
A. 照常继续开发
B. 通知高管
C. 制定风险应对计划
D. 放弃
如果你不采取任何行动，识别风险就是一个无用的过程。你的下一步应该是与可能受影响的人员一起制定风险应对计划。你需要为问题真正发生时制定行动方案。因此，C是正确答案。
规划还可以帮助你预见可能发生的问题。你将能够为它们制定风险应对计划。
有哪些可能出错的事情的例子？如果开发人员生病了怎么办？如果有人辞职了怎么办？如果你的客户联系人变了怎么办？或者你的技术崩溃了怎么办？你将如何处理这些问题？
规划让你能够思考这些问题的解决方案，以便在它们真正发生时有所准备。
规划不仅仅适用于项目的开始阶段。在软件开发中，规划是贯穿整个项目持续进行的事情。软件总是在不断演进，你的计划必须灵活。当你有一个审查计划的流程时，你的项目会变得更加敏捷，这意味着你可以轻松适应变化。
在最初阶段，集思广益地思考可能对项目产生负面影响的场景似乎很耗时，但在没有计划的情况下，在问题发生的紧张时刻仓促应对会更加耗时。在冷静和专注的状态下准备的任何解决方案，都会比在压力下的快速思考更好。
规划可以比作行人过马路。一个行人可以直接走进繁忙的街道，然后听天由命。除非别人注意到了他，否则他很可能会被撞到。这相当于临时性的、无计划的开发。
如果行人先观察车辆，然后在安全的时候前进，他就能安全到达马路对面。这就像在开始开发时寻找风险一样。当然，总会有无法预见的风险，但通过寻找风险并在安全时前进，你增加了成功的机会。
在下一课中，布拉德利将通过一堂关于审查和监控开发进度的课程，将所有流程、需求和规划整合在一起。
本节课总结
在本节课中，我们一起学习了软件产品管理中规划的核心价值。我们了解到，规划的本质是将未来目标转化为当前可执行的任务，并通过准确估算和风险管理来确保项目成功。良好的规划能明确职责、预留测试时间、控制预算和进度，并能预见和应对潜在问题。规划不是一次性的活动，而是一个贯穿项目始终、需要灵活调整的持续过程。记住，提前规划远比在危机中仓促应对更有效。
034：为何需要监控 🎯
在本节课中，我们将要学习软件产品管理中一个至关重要的环节：项目监控。我们将探讨为什么仅仅完成计划是不够的，以及持续监控如何帮助你确保项目按时、按规格交付，并避免常见的开发陷阱。
上一节我们介绍了项目规划的重要性，本节中我们来看看当规划完成后，进入实际开发阶段时，产品经理需要做什么。
你知道在项目中建立流程以确保不偏离轨道是必要的，摩根在之前的课程中已经详细阐述过这一点。你也知道以有效的方式从客户那里获取需求非常重要，我们曾一起讨论过这个话题。你还学习了为何需要持续为开发制定有用的计划，这由摩根在上节课中进行了讲解。
在本节课中，我将告诉你，当所有规划都完成后，你开始实际构建软件项目时会发生什么。作为产品经理，你不能只是退后一步，看着开发团队自行其是。为了确保项目按计划进行，你必须积极地监控、分析和评审你的进展。
设想这样一个场景：你正在为客户委托的一个项目工作。你已经建立了开发流程，明确了需求，并完成了所有规划。你的开发团队正愉快地为项目编写代码，一切似乎都按计划进行。几周过去了，然后是几个月，现在距离截止日期只有两周了。你看了看项目结束时仍需开发的内容，然后慌了神——你至少还有一个月的开发工作要做。你将不得不告诉客户你无法按时交付。突然间，你的开发团队开始加班加点赶工。办公室里散落着空罐子和咖啡杯。你的开发人员开始生病、精疲力尽。产品质量一落千丈。现在你焦头烂额，因为客户正在指责你没有遵守先前约定的截止日期。当一切看起来都进展顺利时，你是如何陷入这种境地的？
遗憾的是，这种情况在软件开发中非常普遍。个人忙碌并不足以确保有效的进展。仅凭“感觉良好”来衡量项目的真实进度是不可靠的。如果你有过软件开发经验，很可能对“赶工”现象再熟悉不过——当项目截止日期意外临近，而仍有大量工作未完成时就会发生。如果你从一开始就监控项目的进展，或许就能完全避免这种情况。
但不必担心，几十年来，软件开发社区已经建立了一套行之有效的实践方法来避免我刚才描述的问题场景。现在你了解了监控进展为何重要，让我们看看你是否还记得一些原因。
以下是关于监控原因的一个思考题：
斯科特是一名软件产品经理。由于客户不断改变对产品功能的要求，并且他的开发团队工作速度不够快，他将要错过一个重要的截止日期。他对客户在项目中的“多管闲事”感到沮丧，并认为跟踪开发人员的个人工作将使他能够在他们表现不佳时采取纠正措施。
请选择斯科特通过监控能解决的问题：
A. 适应不断变化的产品需求。
B. 避免解雇效率最低的开发人员。
C. 不受客户干扰地工作。
D. 满足项目计划截止日期。
监控帮助我们适应变化并满足截止日期。 虽然监控进展允许你跟踪开发人员的生产力，但这不应被视为评估他们职业发展的方式。它也不应替代与客户的良好沟通。因此，正确答案是A和D。
速度只是我们监控进展的方式之一。它只是让你能轻松识别何时出现问题，并做出适当调整以解决问题的一种方法。你也可以识别项目中进展顺利的部分，并庆祝这些小小的胜利。这不仅能让你的项目保持在正轨上，并在交付给客户时提高其质量，还能提升团队的士气，并在项目内部提供高度的透明度。
我需要澄清一点：透明度并不意味着跟踪开发团队的进展却对他们保密。透明度意味着团队中的每个人（而不仅仅是管理层）都知道项目的状态。当开发团队和产品经理以积极的目标驱动和团队合作的心态共同监控进展时，监控项目可以成为一种凝聚团队的方式。没有人喜欢赶工，而监控是团队可以用来互相帮助、避免熬夜和长时间加班的一种方法。
现在你已经看到了监控如何影响团队，让我们测试一下你的知识。
罗斯是一名产品经理，正与他的开发团队一起进行一个项目。他选择分享他在整个项目中所跟踪的细节，以便让整个团队都了解情况。
他正在实施监控的哪个方面？
A. 协作
B. 可见性
C. 验证
D. 确认
可见性是我们用来描述团队中每个人都知道项目状态的词语。这使得B成为正确答案。虽然监控通常会因更多的讨论而促进开发团队内部的协作，但罗斯在这里并非专门实施这一点。验证和确认用于描述软件工程的其他协作方面，而非此处的场景。
所以，监控进展的核心在于按时、按规格交付产品的理念。当然，这有助于开发出更好的软件，并最终让客户更满意。但监控的意义远不止于在紧张的时间表下创造出色的产品。如果做得好，监控可以成为一种极好的方式，来建立共同的目标感，并让你的开发人员感受到自己是紧密团结的团队的一部分。
如果你想了解更多关于这方面的内容，我鼓励你加入本专业课程的最后一门课程。在那里，我将更深入地探讨你可以用来监控和评审项目的具体方法。
你已经完成了第一门课程，恭喜你！希望你已经对软件产品管理专业课程后续内容有了很好的了解。我们在短时间内涵盖了大量材料，还有更多内容等待探索。
以下是我们在第一门课程中涵盖的内容概述：
- 第一模块是课程介绍。肯泛泛地谈了为什么软件产品经理很重要，以及我们可以做些什么来帮助开发团队创造更好的软件。然后他概述了本专业课程的结构以及你可以从中期待什么。
- 第二模块，我们深入细节。我们探讨了为什么你需要拥有流程、需求、规划和评审技术才能取得成功。
我真诚地希望你能从这些课程中学到一些东西，并希望你能将其应用到未来的项目中。我们设计了这个专业课程的后两门课程，你可以按任意顺序学习。它们将为你学习规划课程做好准备，我们设计规划课程在你完成这两门入门课程后学习。无论你最终先学习哪门课程，我们都非常期待与你一同踏上这段旅程。
再见。
浙公网安备 33010602011771号