第八章 需求分析
8.1 软件需求
①获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求；需求还可以来自各种管理机构；需求不仅来自外界，还可以来自软件企业本身；需求还可以来自技术团队本身；有些需求的目的是要更好地了解用户的行为和需求。
②分析和定义需求
③验证需求
④在软件产品的生命周期中管理需求
8.2 软件产品的利益相关者
8.3 获取用户需求——用户调查
几种常用的用户调研方法：焦点小组、深入面谈、卡片分类、用户调查问卷、用户日志研究、人类学调查、眼动追踪研究、快速原型调研、A/B测试
8.4 竞争性需求分析的框架——NABCD模型
1. N（Need，需求）
你的创意解决了用户的什么需求？这个需求可以是明确的、公开的（例如：希望能上网玩三国杀）也可能是说不清道不明的，例如——以前没人说：嗯，如果我能找到这样一个网站，我可以去偷菜，就好了……我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。
2. A（Approach，做法）
好，你找到了需求，下一步怎么办，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。你不能说我会C++，所以我一定可以写好这个软件。你得有独特的办法，例如，有人脸识别技术，会做超大规模的数据处理。那你（你的团队）会什么呢？只会冒泡排序？这些招数不光是技术上的，也可以是商业模式上的（例如，我们第一个做众包的服务）、地域的（例如，我们对本市的公交线路很熟）、人脉的（例如，我们认识很多大学生）、行业的（例如，我们有地图测绘行业的资质），或者是成本上的（例如，我们能找到更便宜的资源来维护网站）。
3. B（Benefit，好处）
这时候你已经有了独特的做法，那你这个产品/服务会给客户/用户带来什么好处呢？如果用户已经有一个解决方案（例如用户已经在用QQ聊天），那你的新的聊天软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？这还有一个用户迁移成本的问题——用户要花费多少精力、时间、金钱才能得到你的产品的好处？如果你要求用户必须有8GB内存、最好的显卡、10Mbps以上的宽带连接，才能使用你的“更好的”视频聊天工具，那么会有多少用户愿意支付这个成本呢？
4. C（Competitors，竞争）
竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么？你的产品如果不是最先进入某个市场的，你还能赢么？先进入市场的产品，有所谓的先发优势（FirstMover Advantage，FMA），当然也有劣势。后面进入市场的产品，有种种不利的因素，但是也有后发优势（Second Mover Advantage，SMA）。
5. D（Delivery，推广）
在实际项目中经历多次的NABC之后，许多人意识到这个框架还应该加一个元素D：Delivery。怎样把你的创新产品交到用户的手中？例一，你想到了一个好主意，建一个比hao123更好的导航页面！我们姑且认为NABC都没问题，那如何把这么好、这么简单的产品交到（Deliver）用户手中呢？例二，你想到了一个手机的应用，NABC都不错，那如何把产品交到千万个用户手中呢？
8.5 功能的定位和优先级
杀手功能、外围功能、必要需求、辅助需求
我们以一个英汉词典软件为例子来说明。
杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等
外围功能：良好的界面设计，在各个平台上都能运行
必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）
辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）
这四个象限能让软件团队清楚地看到自己感兴趣的功能处于什么地位，有了这些分析，我们就可以决定怎么处理不同类型的功能。 重要的是，不要把资源平摊到所有象限中，而是倾斜到可以产生差异化和独特用户价值的地方。
8.7 分而治之（Work Breakdown Structure）
一个团队项目要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，同时还希望项目能维持良好的技术架构，以便持续开发，千头万绪，从哪里入手？WBS就是一个例子
WBS通常从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。这样的分割可以持续下去，直到WBS的使用者（开发团队、接收方）达到共识。从数据结构方面来看，WBS分割的结果是一棵树。所有子节点都最终有一个根节点。每个节点描述的是要交付的产品或文档，而不是开发团队的努力或花费（各个叶节点的成本可以作为次节点的属性展现出来）。做好WBS的几个要点：
- 保证所有子节点覆盖了全部父节点包含的内容
- 保证各个子节点不要相互覆盖
叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止
从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发
第九章 项目经理
9.1PM是啥
软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理——PM
PM的M就是Manager，但是P有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同。接下来介绍的是项目经理——Program Manager
- Product Manager：产品经理——正确地做产品
- Project Manager：项目经理——正确地做流程
- Program Manager：微软的职位名称
微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划（Product Planner），他们和市场部门的专职人员一起，负责产品的长期发展和市场推广
9.4 PM 的能力要求和任务
能力要求：
1. 观察、理解和快速学习能力——PM要能够在一个新的领域中很快上手
2. 分析管理能力
每天项目中发生的事情千头万绪，PM要能够分析出重点，找到优先级，做判断、做决定……一个项目和一个人一样，每天都会碰到各种问题：
- 重要而紧急的
- 网站崩了！
- 程序员小飞突然提出离职！
- 重要而不紧急的
- 按照流量和内容的发展趋势，三个月后，目前的架构似乎撑不住，但是现在还凑合……
- 程序员们都不写文档，他们三个月前说等忙过之后会写的，但是……
- 不重要而紧急的
- 老板的老板问到了项目的进度！要写一个PPT，向若干人征求意见，并及时得到反馈
- 不重要且不紧急的
- 领导想召开全公司大会，要表演节目……
3. 一定的专业能力
如果一定要说专业能力的话，PM的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意？你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法？PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解
4. 自省的能力
一个PM做第一个项目时可以拍脑袋定工期，拍胸脯打包票，最后拍屁股走人（谁没年轻过呢），但是失败之后要有自省和自我改进的能力