构建之法-8.9.10

第八章:需求分析
读完了《构建之法》第八章-需求分析之后，发现在前阵子做了一个小程序中遇到的问题迎刃而解了，
只要在动手之前考虑分析好软件具备什么功能要为什么类型的人服务等等，
那么在实现的过程中将会更加顺畅，不至于边做边改，边改边删……
下面总结下对第八章的理解：
在开始一个项目之前，团队要去了解多方面需求，获取和引导需求、分析定义需求、验证需求、在软件生存期间的管理需求；
从这些常规的需求分析中，团队获悉用户需求，并根据这些来实现“必要”的功能。选择实现哪些功能，抛弃过时的功能，在项目的实现过程中不断的更新需求，完善技术，增加功能；
另一方面可以从软件的功能性需求，产品开发过程需求，非公能性需求，综合需求等等。
相对一第一种分析，这种需求分析更着重于对实际用户的隐形需求，就像是订票系统中查票订票结果返回的及时性，股市交易的更新准时性等等.

这些在需求阶段，软件团队就要和客户代表把这些问题定义清楚。

分析完需求之后就是要考虑下利益相关者了，例如直接使用软件的用户、购买软件或者根据合同接收软件的顾客、再者是市场分析师、监管机构、软件工程师等。
当然，软件开发无法一次性就满足所有利益相关者的要求，但是我们一定要在这个阶段给他们机会提出他们的需求和意见，清楚他们想从软件中获悉什么！
知道了用户需求，但是为了避免出现“秋千图”的情况，就要
知道用户真正的需求是什么，软件团队便可以通过下面几种调研方式去
1.焦点小组,要求会议的组织者要有很强的组织能力，能让不同的角色都充分的表达意见，并如实地总结这些意见。
2.深入面谈，通常是一对一的深入交流了解，比较费力！只能是使用某些特定的领域。
3.卡片分类，根据收集回来的用户杂乱无章的真正需求进行分类整理然后不断repeat 讨论-->明晰定义-->归类-->排序 来进行统一软件需求。
4.用户调查问卷，规定好问题然用户回答,不过要精确好问题.
5.用户日志研究，要求用户用日志形式记录下日常的软件的行为供团队分析，需要用户有强大的自律能力。
6.民族志/人类学调查，设身处地的参与到用户群体中去，去获取分析需求。
7.眼动跟踪研究,用科学的仪器跟踪用户的实现，获取用户想要看到的信息位于哪里是什么等等。
8.快速原型调研，实现一个简单的原型，根据用户使用之后的反馈进行跟新，也是一种用户参与式设计。
9.A/B测试，实现出A/B两个版本，然后发布到部分精选出来的用户中进行反馈,得到improvement。

在清楚了真正要的是什么之后就应该考虑下软件的杀手锏是什么亮点是什么--创新,也就是分析竞争性需求的框架.并不是随便的“二拍”的办法来解决.这里有个例子
NABCD.
需求（Need）--> 做法（Approach）-->好处（Benefit）--> 竞争 （Competition）-->推广（Delivery）
最后根据四象限方法进行功能定位，让团队清楚的看到自己感兴趣的功能处于什么地位，有了这些分析我们就可以根据下面五种方法对有限的资源进行合理有效的分配：
.维持---以最低的成本 维持此功能
.抵消---快速地叨叨“足够好”、“和竞争对手差不多”。
.优化---花最大的力气做到并保持行业最好
.差异化---产生同类产品不比不了的功能或优势（我有人无的优势，或者一个数量级以上的优势）
.不做---砍掉一个功能也是一个办法，我们并不是要做所有的功能。

根据这样的分析分析再分析不说别的，但相比较以前一定是有一个提升的.

question:需求分析的确是很重要的，读完第八章之后，觉得需求分析是不是充斥整个项目的生命期呢？那么在项目开始之初，我们的分析又是应该要做到哪个程度才开始下一步的工作？

 第九章 项目经理

在上面讲了团队中做分析的人员，加上前面的打码人员（大妈们）现在来论PM（Project/Program/Product  Manager）的重要性.

Product Manager 在一个项目中项目经理要负责根据市场和用户要求，协调各部门的资源，正确把握产品定位和方向，解决用户的痛点，持续优化产品。

Project Manager 对整个项目的流程负责，保证项目顺利按计划发布.

Program Manager 在微软的职位名称，就是要负责出产品开发和测试之外的所有事情.

要成为一个团队的 PM 需要具备观察、理解和快速学习能力，要能够在一个新的领域中很快上手，并能够在用户的角度上考虑问题，体会团队成员的言外之意等等;

分析管理能力，每天项目中会出现无数问题PM 要能够分析并找到优先级，做出决断;销售交流能力，PM始终都要和客户进行交互，兜售商品;一定的专业能力，PM要具有理解表达能力，能借助工具（如：excel等）来绘图，码字表达自己的清晰想法.再者就是自省能力，一个PM做第一个项目时走”三拍“路线，但是最后失败后要有自省和自我改进的能力，否则是无法成功的做好PM,这也是很重要的.

总是PM就像是团队员工和用户之间的”翻译“ 负责体会用户的”非专业化“需求表达,并转变成团队中的”专业“术语.不断在协调关系，既要做好用户兜售，也要对团队人员的负责引领工作，推动项目顺利的前进.

第十章 典型用户和场景

这个章节主要强调的是典型用户与场景，什么是典型用户?这里大致分成三类:A(个体户),你的项目对此类人来说只是一个“工具”，当前需要，但以后不一定需要;B(巨头类),真正了解你的项目，而且对项目产品有稳定的需求。C(无关类)，拥有不正当目的而使用产品.

对于典型用户的分析，可以根据几个属性：性别/年龄，职业，收入，知识层次和能力，动机/目的/困难，生活/工作情况 等等.

对于场景，我的理解就是，将自己设身处地的代进去用户的身份中，体会要完成一个目标的所有必须经历的过程，这一切组成了一个Story也就是场景.

场景能够使团队人员更好的对项目进行完善更新，维护等等.

在需求分析推动进程-PM管理-最后再在场景维护下，一个项目的基本流程框架中的部分就呈现出来了.