本周看了《构建之法》的第八、九章的内容。初步了解了开始做一个软件的初始步骤。

需求分析

1.寻找需求

获取和引导需求。需求不仅是来自外界，甚至也可以来自技术成员团队内部；

分析和定义需求。主要是对需求进行量化；

验证需求。主要跟利益相关者沟通并通过各种方式像其验证对需求的认知。

在软件产品的生命周期中管理需求。需求不一定只在初期才有；在中后期的时候可能因为外界环境变化甚至是成员自身水平变化而出现新的需求

也可从不同角度划分：

对产品功能性需求、对产品开发过程需求、非功能性需求、综合需求

2.软件产品的利益相关者

最终用户（直接使用软件系统的人）

顾客（购买软件或接收软件的人）

市场分析师(代表“典型用户”的需求)

监管机构(对软件是否符合行业和政策规定的监管)

软件工程师

3.获取用户需求的方法

焦点小组（focus group）：找到一群用户的代表，加上利益相关者来讨论用户想要什么

深入面谈（in-depth interview）:采取一对一的采访方式，着重探究用户在使用的时候有哪些困难

卡片分类（card sorting）：将杂乱无章的需求分条目地写到卡片上，然后对这些卡片进行讨论、归类甚至排序

用户调查问卷(User Survey)：向用户提供事先规定好的问题，让用户回答。(注意调查问卷的方式及应该规避的错误)

人类学调查（ethnographic study）：和目标用户“同吃同住同劳动”——以便真正理解用户有什么需求、为什么用户有这些需求

眼动跟踪研究(Eye Tracking)：如何在网页上向用户更好，更完整的展示信 

快速原型调研

A/B测试

4.竞争性需求分析（以说服别人）

以NABCD模型为例

1. N——NEED需求

2. A——APPROACH做法 - 有什么（独特的）做法去解决用户的困难

3. B——BENEFIT好处 - 特别注意用户迁移成本的问题。指的是用户要得到我们所做的软件带来的好处，需要花费多少时间、金钱甚至精力（去转移使用）

4. C——COMPETITORS竞争

5. D——DELIVERY推广

5.功能定位和优先级

要把用户从竞争对手那里吸引过来，团队自己的产品要有一个差异化的焦点，在这个焦点上，我们的团队能做得比别人好10倍，高一个数量级。 于是我们有了两种不同类型的功能：杀手功能（core）/外围功能（context） 还有另外一种划分：必要需求/辅助需求

6.计划和估计

首先分清几个概念：目标、估计和决心

7.分而治之

WBS通常从最终的产品开始，一层一层往下，把大型交付件（deliverable）分割为小型、具体的交付件（从结果出发，而不是团队的活动）

 项目经理

PM中的M是“manager”（中文翻译为经理）其实是个很广泛的概念。而P在也这有多种意思。

1、PM是啥

product manager：产品经理。正确地做产品(即产品经理是以产品为中心展开工作，包括产品的定位、运营、优化等等)

project manager：项目经理。正确地做流程；保证一个项目顺利按照计划结项。

program manager：微软独有的PM，与项目经理类似但又有不同

PM最大、最独特的贡献是带领团队达成最重要的目标，并保持团队的平衡

2、风险管理

层次一:啊呀，大问题

层次二：缓和并防止问题。先把问题缓和下来再进一步调动队员解决问题

层次三：预计。从定性的猜测进不到定量的预计，从而有效地做准备

层次四：把问题变为机会（比如从问题的改进中使得产品获得更大的优势）

3、PM的能力要求和任务

观察、快速理解和学习能力。这是因为PM有时候很像一个渠道去沟通不同的部门或者角色，所以需要很强的适应能力，而这种适应能力就是从观察中理解和学习的能力

分析管理能力。不论是自我的管理还是千头万绪的需求中快速分解“有用项”的能力，都可以算在其中

一定的专业能力

总得来说，PM的能力主要有:学习能力、观察理解能力、分析管理能力、销售能力、交流能力、处理冲突的能力、一定的专业能力、自省的能力

PM的任务

带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计

管理软件的具体功能的生命周期

创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍。

代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级

分析并带领其他成员形成对缺陷/变更需求的一致意见，并确保实施。

带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布让客户满意的软件

收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

《构建之法》（四）