[I.1] 个人作业：阅读和提问

[1.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	个人作业：阅读和提问
我在这个课程的目标是	了解软件开发基本流程，能够与团队共同开发完成一个软件项目
这个作业在哪个具体方面帮助我实现目标	了解软件开发思想与流程，锻炼思考能力

---

问题一：结对编程中的角色为什么需要互换，以及何时互换？

结对编程中有两个角色：

（a）驾驶员（Driver）是控制键盘输入的人。

（b）领航员（Navigator）起到领航、提醒的作用。

这两个角色是可以互换的。和现实生活中的例子类似，一个人负责具体的执行（驾驶，用键盘编辑程序等），另一人负责导航、检查、掩护等。

讲义的第三部分《两人合作》中提到结对编程，在结对编程时，我们可能总是倾向于让技术更好的同学当 “驾驶员”，另一位同学当 “领航员”。但 “结对编程的核心是知识共享和互相学习”。资料发现有研究表明，定期轮换角色可以显著提高团队的整体技术水平。
如果两人各司其职，会对自己的职责任务更了解，如果角色轮换过于频繁，会不会导致风格不统一，思路存在分歧，从而增加后期维护的难度？如何衡量什么时候才是合适的互换时机，另外，在时间紧迫的项目中，是否应该牺牲 “知识共享” 来换取 “开发效率”？

问题二：什么程度的用户调查是有意义的，如何在做过头和调查不充分中平衡？

做过头了会怎样?

我们有这么多各式各样的工具, 互联网给我们带来了这么多用户和数据, 这是好事, 也有副作用。

世界上能访问用户数据, 并根据数据做分析和改进的公司, 大概 Google 是其中翘楚, 这种 >data-centric 的做法做过了头, 也有悲剧发生:

Douglas Bowman 曾经是Google 的视觉设计主管, 2009 年的一天, 他受不了了:

Yes, it's true that a team at Google couldn't decide between two blues, so they're >testing 41 shades between each blue to see which one performs better. I had a >recent debate over whether a border should be 3, 4, or 5 pixels wide, and was asked to >prove my case. I can't operate in an environment like that. I've grown tired of >debating such minuscule design decisions...

当你的公司要你用数据来证明 41 种蓝色到底哪一种更好, 或者为一个边栏宽度是3, 4, 或5 而争执不休, 纷纷表示要拿数据来证明的时候, 你怎么办?

如何界定用户调查的 核心边界？哪些问题比如核心功能需求、用户痛点等必须通过深入调查验证，哪些细节比如界面配色、边框像素等无需过度纠结？像 Google 测试 41 种蓝色的行为，显然超出了合理边界，但在实际项目中，如何量化出来哪些细节值得调研，避免陷入无意义的精细化数据之争？在资源有限的情况下，如何平衡调查的深度与效率？数据驱动与专业判断如何协同？在用户调查中，数据的参考权重应该是多少？当数据结论与设计师、产品经理的专业经验相悖时，应该如何取舍？比如数据显示某款 “低饱和度蓝色”点击率更高，但设计师认为该颜色与品牌调性不符，此时该以数据为准还是以专业判断为准？

问题三：用户界面评估标准是否必须严格遵守这十条原则？或者与其他因素冲突了该如何评价？

[注] 如何评估用户界面? 可以参考 Nielsen的启发式十条原则

01 可视性原则
系统状态有反馈，等待时间要合适

02 系统界面符合现实惯例
使用用户语言而不是开发者语言，贴近生活实际而不是学术概念或开发者的概念。

03 用户有自由控制权

操作失误可回退

04 一致性和标准化
同一事物和同类操作的表示用语要各处保持一致

05 预防用户出错
关键操作有确认提示，及早消除误操作

06 减少记忆负担
识别胜于回忆，提供必要的信息提示（可视&易取），减少记忆负担

07 使用效率和灵活性

为新手和专家设计定制化的操作方式，快捷操作可调整。

08 易读性
减少无关信息，体现简洁美感

在实际的很多应用中，用户界面的使用不仅不符合这十条原则，甚至恰恰相反，系统故意设计不可跳过超长等待时间，用作投放开屏广告，用户一旦点到应用本身或外部应用广告的界面，返回卡顿难如登天，界面设计不符合惯例，使得用户找不到关闭广告的的按钮，在用户界面的设计明显不遵守这些原则，因为商业化的盈利需求而破坏这些原则，应该如何评价这样的行为呢？用户界面的设计应该更倾向于使用者利益还是赞助商利益？

问题四：在一个创新想法的起步阶段如何判断是否能吸引到大众？

但是很多新技术都掉到沟里去了，新技术带来的好处未能吸引到大众，是一个重要原因

在16章行业的创新中提到i创新的重要性，在创新想法刚起步的时候，我们要怎么准确判断，这项技术带来的好处，是不是真的能对上大众的真实需求？很多技术性创新本身门槛就高，做技术的人很容易陷入“自嗨”，只顾着技术够不够先进、够不够酷，却忽略了普通人到底会不会用、能不能用、愿不愿意用。
同时，创新落地和风险控制之间也很难平衡。如果抱着“先做出来再说” 的心态，很可能投入大量时间和成本，最后做出的东西没人用，白白浪费资源；可如果一直犹豫、反复验证能不能吸引大众，又很容易错过时机，被别人抢先一步。
在项目最开始，有没有一套实际能用的判断标准？比如需求够不够迫切、实现成本高不高、有没有不可替代的价值，依靠这些来决定这个创新到底要不要继续做、又该往哪个方向调整。
还有一个很现实的问题：怎么面对创新的延迟效应？有些技术刚出来时不被看好，不是因为不好，而是当时的环境、生活习惯、配套设施还没跟上。就像二维码，早年出现时几乎没人用，等到智能手机和移动支付普及后，才突然变成人人离不开的工具。
那么在起步阶段，我们要怎么区分：一个创新是暂时不被理解，还是真的没有市场？哪些值得坚持等风来，哪些应该及时止损、及时调整？技术性创新通常开发和维护成本都不低。在最开始，我们又该怎么大致判断：这项技术未来带来的价值，能不能覆盖长期的成本？

问题五： 用户体验和产品质量冲突时，该如何平衡，或许怎么具体判断更倾向哪一方面？

好的用户体验当然是所有人都想要的，如果它和产品质量有冲突，怎么办，牺牲质量去追求用户体验，用户能接受吗？

在第12章的12.1.6用户体验与质量这样写道。当用户体验和产品质量不能同时满足时，我们到底该偏向哪一边？有没有一套实际、可操作的判断方式，而不是凭感觉决定？比如，一个功能如果追求极致稳定、低错误率，就可能流程繁琐、步骤变多，体验下降；但如果为了一键操作、简洁流畅，又可能带来潜在风险、兼容性变差、甚至影响数据安全。什么样的产品，应该优先保证质量？比如工具类、金融类、系统级软件，是不是稳定性永远比体验更重要？什么样的产品可以适当牺牲一部分质量来换取体验？比如短视频、社交、内容类产品，用户是不是更在意流畅好看，而不是绝对不出错？在实际开发中，有没有具体的判断标准？比如影响范围、出错后果、用户容忍度、开发成本，我们该依据哪些因素来做权衡？书中问到 “牺牲质量去追求用户体验，用户能接受吗”，我也很好奇：用户到底能接受多大程度的不完美？ 哪些质量问题是底线，绝对不能妥协；哪些是可以在体验优先下适度放宽的？

---