构建之法
需求分析
过程
获取和引导需求
分析和定义需求：有多少用户需要，能承受什么价位、实现所需时间与成本、各个需求的优先级
验证需求
软件生命周期中的需求管理：开发过程中需求会产生变化
分类
对产品功能性的需求
对产品开发过程的需求
非功能性的需求：服务质量需求，例如访问速度、并发量等
利益相关者
用户
顾客：购买人
市场部
监管机构
软件工程师
获取用户需求
焦点小组：集中目标用户的代表，加上利益相关者，讨论用户想要什么
深入面谈：可用性、易用性
（以上二者会产生需求分析的结果：用户场景）
卡片分类：对杂乱无章的需求进行整理
用户问卷调查：感觉适用场景更多面向简单的问题，不需要深入交谈，用户可简单做出判断给出答案的问题
民族志/人类学调查
眼动跟踪研究
快速原型
A/B测试
竞争性需求分析的框架
NABCD
N需求：你的创意解决了用户的什么需求？要充分了解用户的痛苦，对已有软件、服务不满意的地方。
A做法：产品的解决方案
B好处：产品能给用户带来什么好处，是否有迁移成本？
C竞争：分析竞争对手的产品，看清楚我方的优势在哪里，我方的劣势在哪里
D推广：如果将产品推广到用户的手中？
功能的定位
四象限法
杀手功能/外围功能
必要需求/辅助需求
必要+杀手：第一象限，差异化，产生同类产品比不了的功能和优势，我有人无，或者一个数量级上的优势，全力以赴投资在这个领域。
必要+外围：第二象限，抵消，快速达到和别人差不多，对于大家都特别看重的功能，采取”优化“的办法，达到行业最佳
辅助+外围：第三象限，维持，以最低代价维持此功能
辅助+杀手：第四象限，建议采取维持的办法，或者现在不做，等待好的时机，或者让小部分人做实验
计划和估计
分清楚几个概念：目标（未必能够实现）、估计（人力物力时间）、决心（保证）
在每一轮估计中，注意探询数值背后的假设，探险者总是高估自己的能力
办法一：参考前人的经验
办法二：快速原型法-用一两个先锋去探路
Y时间=X（估计的时间）+-X/N（类似工作的次数）
分而治之WBS （work breakdown structure）
父节点、子节点、叶子节点
- 保证子节点能够覆盖父节点的所有内容
- 保证各个子节点不要相互覆盖
- 叶子节点要足够小，能够在一个里程碑中完成，成本最好不要超过两周
- 从结果出发构建WBC，而不是从团队的活动出发
Those entrepreneurs who start out with the idea that they’ll make it big - and in a hurry - can be guaranteed failure.
项目经理
一个团队可以有几类PM
- 做功能设计的
- 对商业和客户有很强的了解能力的
- 有广泛的经验和知识面，以及商业拓展能力的
- 驱动流程的，推动团队完成一个版本的开发，准时上线的
- 专门深入某一领域的，例如软件的国际化/本地化等
- 和研究人员合作，琢磨前沿技术如何能进入主流产品，进行技术转化的等等
特点：
- 不是行政领导，和大家平等工作，推动团队完成软件的功能
- 一个团队可以有很多PM
- 和其他团队成员一起形成决议
- 管事不管人
- 一定做具体工作
具体任务
- 带领团队形成团队的目标、远景，把抽象的目标转化成可执行的、具体的、优美的设计
- 管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）
- 创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导而不是障碍
- 代表客户和用户的利益，主动收集用户反馈、预期用户新的需求。协调并决定各种需求的优先级
- 分析并带领其他成员形成对缺陷/变更的一致意见、并确保实施
- 带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布让客户满意的软件
- 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的做缺点，推动项目成员持续改进，从而提振士气
软件设计与实现
典型的开发流程
- 功能需求
- SPEC复审&设计
- 详细设计
- 代码实现
- DEV自测
- 同伴复审
- 源代码同步、合并、构建
- 签入测试
- 提交签入关联Work Item
- 构建成功
- BVT成功
- 自动测试
- 功能全面测试
- 功能完成
- 如果在测试过程中发现BUG，则需BUG分析和修复
开发阶段的一些管理办法
- 每日构建：可以提高团队成员的积极性
- 小强地狱：当某人的BUG超过设定的阈值时，停止开发新功能，进入修改BUG状态，直到BUG数量降低到阈值以下。
- 构建大师：由导致构建失败的人担任，负责管理构建服务器；调试构建，负责找错，并分析出错原因；负责把构建大师称号转给下一任构建失败的成员。
用户体验
用户体验的要素
- 用户的第一印象：用户第一次登录产品，我们想传达给用户一个什么印象？简单，大胆的减法。
- 从用户的角度思考问题：同理心。
- 软件服务始终要记住用户的选择：选择过一次设定后，其他场景或下次都默认这个设定，直至其修改。
- 一次使用与多次使用：一个功能一次性使用感觉好用，但如果多次使用呢？会不会厌烦？或者没有新东西？
- 不让用户犯简单的错误：设计成让用户很难犯错的模式
- 用户体验和质量：是否可以牺牲一些质量，换取让用户体验更好一些？
5W1H
who，谁是我们的目标用户？
when，用户在什么时间段使用我们的产品？
where，用户在什么地方或环境下使用我们的产品？
what，我们的产品是什么？用户想达到什么目的？他们的期待是什么？
why，用户为什么使用我们的产品？和其他竞争产品相比，为什么他们要选择我们？他们的动机是什么？
How，用户是如何与产品发生交互的，他们是怎么用的？在使用过程中有什么问题吗？
用户体验设计的目标和步骤
目标：降低用户的认知阻力，即用户对软件界面的认知（想象某事应该怎么做，想象某操作应该产生什么结果）和实际结果之间的差异。
步骤：
- 概要设计：需求分析阶段，用户要解决的痛苦是什么？如何给用户提供价值？
- 行为（交互）设计：场景设计阶段，通过一系列用户和软件系统的交互，帮助用户解决问题。
- 界面设计：具体实现阶段，通过读取用户的输入，以及创造和改进交互的媒介，帮忙用户进行交互。
几个原则：
- 尽快提供可感触的反馈
- 系统界面符合用户的现实惯例，避免专业术语，而多采用生活化的语言。
- 用户有自由控制权：操作失误可回退，可以定制显示信息的多少，可以定制常用的设置
- 一致性和标准化：用语各处保持一致。
- 适合各种类型的用户：新手、专家、残疾人
- 帮助用户识别、诊断并修复错误：错误操作给出提示和帮助修正错误，关键操作要确认
- 有必要的提示和帮助文档，以及首次进入软件的引导页