本周学习了构建之法的第8、9章，总算是接触到了久闻未见的软件工程中的重中之重——项目需求分析，以及对需求和团队进行管理的重要角色——PM
我们都知道软件是由人手一行行代码写出来的，软件的存在也是为了满足人工作生活中的各种需要。如果软件开发没有目标，那写出来的代码不过就是26个字母及其大小写加上空格和一些特殊符号的随机组合罢了，没有实用意义。所以，代码的诞生一定是为了实现某个或某些具体的目标，也即这些代码最终成型后要实现怎样的功能。为了确立这样一个目标，我们就需要对最终使用到这些代码的人做需求分析，通过分析这些人的需要来订立满足这些需要的目标，进而推进项目的构成。
书中通过几个实例介绍了软件需求到最终确立目标间的一系列过程，从获取和引导需求开始，获取后对需求进行分析和定义，再到验证需求并在软件产品的生命周期中不断管理需求、更新需求。需求按照不同角度又可分为：对产品功能性的需求、对产品开发过程的需求、非功能性需求及综合需求。需求来自软件产品的利益相关者，如用户、客户、市场分析师、监管机构甚至软件团队本身。获取用户需求也有很多种方法，书中着重介绍了用户调研并列举了一些常见的调研方法：焦点小组，深入面谈，卡片分类，用户调查问卷，用户日志研究，人类学调查，眼动跟踪研究，快速原型调研以及A/B测试。互联网给我们带来了用户和数据，我们能够方便的分析其中的规律以确立用户需求，但过分强调数据的作用也可能产生负作用，因此要注意合理应用。同时，书中还介绍了竞争性需求分析NABCD框架，从N（Need需求）到A（Approach做法），再说明这样做会产生的B（Benefit好处），以及与同类产品的竞争性C（Competitors），再到实际的推向用户群体D（Delivery推广）。
确认需求后进行开发时，也要注意各个功能的优先顺序及其定位，最简单的可分为必要需求和辅助需求，顾名思义很好理解。以及常在各种科技博文中能见到的名词——杀手功能，与之相对的则是外围功能。产品的核心竞争力往往来自杀手功能和必要需求，而辅助需求和外围功能的优劣则很大程度上能影响用户体验并决定用户粘性。
项目开发中另外一项非常重要的成分就是计划和估计。我们的产品什么时候能达到预期进度？什么时候能够交付使用？为此我们可以确立一个目标，并对进度进行大概的估计，并且抱有必要的决心。
而在具体的开发中，对一项任务进行分割并分配的水平如何往往能在很大程度上决定项目开发的效率和质量，此即“分而治之”思想。早期的项目开发大多针对的功能比较小，团队成员数量也较少，成员间交流也比较简单，因而没有专门的人员负责任务分配及对内/外交流这一方面。随着产业的发展，开发和交流的矛盾日益凸显，因而产生了PM——“项目经理”这一专司任务分配和团队管理、交流的职位。PM最重要的任务就是正确地做产品、做流程，保证一个项目顺利地、按计划结项，并在一定层面上确保产品的长期发展和市场推广。普通的程序员的任务成果一般是具体的代码，而PM的任务成果则更多的是规格说明书（Spec），同时PM需要处理与客户交谈、组织用户调研发现用户需求、了解和比较竞争产品、分析如何让软件变得可用、有用以及如何高进团队流程等任务。按照不同的任务职责，PM也可以分为几类，书中第9章以微软公司内部的组成为例向我们介绍了诸如做功能设计的PM、对商业和客户有很强了解能力的PM、具有广泛的经验和知识面及商业拓展能力的PM、驱动流程的PM、专门深入某一领域的PM以及和研究人员合作、将前沿技术引入主流产品做技术转化的PM。
在很多时候，PM作为项目的领导对项目进展起着控制方向的作用。在软件开发过程中还要面临很多不确定的风险，对风险进行分析、规避和管理也是PM的职责之一。书中在介绍了PM诸多的工作任务的同时也介绍了几点PM应该具备的能力要求，如：观察、理解和快速学习的能力、分析和管理的能力、一定的专业素质、自省和改进的能力。总的来讲，PM在一个项目中的具体任务一般可以归为以下几点：带领团队形成团队目标，管理软件的具体功能的生命周期，创建并维护软件的规格说明书，代表客户和用户的利益、主动收集用户反馈、预期用户新的需求、协调并决定各种需求，分析并带领其他成员对缺陷/变更需求形成一致意见并确保实施，带领其他成员确保项目保持功能/时间/资源的合理平衡并跟踪项目进展、确保团队能够发布零客户满意的软件，收集各类数据、客观分析项目实施过程中的优缺点并推动项目成员持续改进、提振士气。同时，PM也要具有发现身边成员闪光点、说服他人的能力。