工业互联网：7 项目生命周期管理（1） - 好文

7   项目生命周期管理

本章将一个工业物联网解决方案的生命周期按照大体的时间顺序划分为：方案企划、设计论证、实施部署、运行改进和业务退出，并在本章中分别讲述。没有理由相信这种划分方式是唯一正确的，因为无论我们将一个工业物联网解决方案当作项目还是产品来运营，其管理实际上都是一种“最佳实践”的艺术。也就是说，有很多实际上等价的方式来划分一个解决方案的生命周期，怎么划分无非是不同领域的专业人员从自身经验和业务特点而产生的不同偏好。

7.1   方案企划

方案企划过程的目的是深入理解用户的需求的实质。该阶段包括相互交织的需求获取和需求分析两个过程。这个阶段不仅仅是后续阶段的起点和基础，也是后续阶段的终点。也就是说，在之后的每个阶段中，方案的实施团队都会不断地在工作中再现和回顾需求分析的结果，甚至是需求分析的基本假设，来验证当前阶段的阶段性工作的合理性。之所以会这样，因为需求分析过程实际上产生的是整个方案生命周期的行动纲领，以及方案实施团队和用户的业务接口。

好的开始是成功的一半，实践中常见一些方案因为从一开始就定错了方向而导致失败。所以方案企划的重要性，怎么说都不为过。总的来说，我们可以认为需要先获取需求，然后加以分析理解，进而编织需求文档来描述下来以供评审。但就像前面所说的，整个过程是一个多重循环的迭代，任何一个环节都有可能由于新的发现而将你带回到之前的某个（不见得是最初的步骤）步骤。所以，如果你在某个时刻突然发现自己已经无法分清目前是处于哪一个步骤了，不用惊慌，这只能说明你对问题的理解正在加深。记得有项目管理领域中的一句老话：你最了解项目的时候，是项目验收交付以后。

7.1.1   需求获取

首先必须还要啰嗦一句的是，与常见的观念不同，需求的获取实际上是一个贯穿整个解决方案周期的活动。不过在本章节，主要还是聚焦于初始的需求获取，也就是一般概念中的最初的创意的源泉。至于如何在其他阶段渗透式地获取新的需求的修正，将在论述其他阶段的章节一并提及。

7.1.1.1   需求获取的方法
一、（直接）干系人访谈

这里所谓直接干系人，是指和解决方案的实施有最直接的利益关系的人群，比如用户，付款者。访谈的方式可能是被使用得最多的，而且经常是你无意地、自发地就在使用的。但是这种方法的有效性并不容易保证。并不是说作为一个好的访谈正必须是那种性格外向、和什么都能打交道的人，实际上，人际交往的技巧主要用在敲开最初的大门以及会谈中如何控制会谈的进展围绕向你所需要解决的问题而运转，而对客户群体和目标业务的洞察才是访谈有效性的关键，也是会谈的组织者如何确保不偏离主题的立基点。另外还要注意的是，人际交往的能力和业务的洞察力并不见得是由一个人来实现的，而有可能是一个团队。这个团队的典型人数是2人：一个负责与客户的谈话，一般由销售人员扮演；一个负责信息的挖掘和收集，由产品经理、责任工程师来扮演。

和任何会议一样，访谈之前必须有足够的准备工作来确保其有效性，这一点就需要相关背景的调研和预先的初步分析。对于公开信息的分析，可以参考下面的段落；而非公开信息的获取却是一个长期的贯穿一个方案设计者的职业生涯的过程。这里面时间是一个关键的因素，因为你必须花上足够的时间和你的目标用户群体的各类角色交往甚至建立个人友谊，才可能在他们的一次无意的抱怨中获得灵感。中国的民间智慧中，常说“改行穷三年”和“不熟不做”，其实说的就是这个道理。当然和做任何事情一样，要做好还需要必要的技能，因为好的技能可以缩短你了解一个领域的时间。这里要重点说的技能就是对公开信息和专家意见的捕捉和消化。

二、公开信息

在搜索引擎被广泛使用之前，只有书籍和专业杂志的综述性文章才是你在短时间内系统地了解一个领域的方法，但这个方法的问题主要有两个：第一是系统化的组织的知识看起来很吓人，因为那厚厚的一本书让我们联想起大学中另一个专业的专业课教材。第二是时效性，也就是说，当这些知识被系统地整理起来的时候，往往已经和产业界中的实际情况已经有数年的差异。

但是请永远也不要忽视公开的、已经被体系化整理的知识的力量，因为这些知识往往仍然是形成领域现状的基础。即便是关于我们常常认为是瞬息万变的消费类市场领域，那些心理学和文化的运作原理实际上在人类的几千年的历史中并没有根本性的改变。读古人的书是必要的，何况这些专业书籍和文章还没有那么古。体系化的知识提供了一个坐标原点，以帮助你根据通过其他方式收集的即时信息修正自己的理解。那种“难道我要学习另一门学科吗”的畏惧感是不必要的，要对自己的大脑有这个自信：大学中各工科专业的专业课时间并不长，更长的时间实际是都是在学习类似的基础课，不是么？何况，你只是要为目标领域打造一个解决方案，这意味着你所需要的更多的只是该目标领域知识的一个侧面，而不是全部，所以你在浏览该目标领域的体系化知识的时候更多的是跳跃和选择的，而不是地毯式的搜索或者叫你要拿那个领域的学位。

互联网是另一个收集公开信息的手段。但是你要了解自己要查什么。一个缺乏体系性知识的人往往在搜索引擎之前茫然无措，只能反复将最初的问题拆解成几个关键词来输入，而这些关键词也许是肤浅的，或者是因为该问题在领域中刚刚得到关注而完全搜索不到任何有价值的内容。

三、专家意见

对一个新进该领域的人来说，有机会找到一个领域专家进行一次议题相对开放的会谈是一个快速入门的好办法。行业中有各知名企业的从业人员、各种协会和科研机构人员、大学教授和研究生，还有政府中主管该领域的公务员，这些都是很好的专家群体。你需要结识他们的方式，比如直接登门拜访、行业展会和研讨会上的茶歇会谈等等。专业人士的职业天性一般都会促使他们和你愉快地交谈，但是你也必须要注意一些基本的社交礼仪，比如你不能让对方感到你在刺探对方的商业机密。

在收集专家意见的时候特别要注意，对于获取的意见要批判接受。不是说大多数专家赞同或反对的就一定对或不对，如果行业里的共识太普遍，也许这正是问题的根源。比如在企业信息化刚出现的时候，各路专家实际上心里都有一种对“电脑取代人脑”的恐惧而不肯拥抱计算机所带来的变革，从而会对你所说的任何以信息化提升工作效率的提议都是否定和抵触的。这种抵触并不是简单的说“否”，而是会给你一大堆的看似有道理的理由，如果你没有足够的成体系的该领域知识来形成反问句，此时的你也许已经把自己的创意在心中否定了。

还有就是，多数的专家所能提供的都是一般性的答案，也就是目前普遍而言正确的答案。而你要构建的解决方案可能是要解决某个客户的非常个性化的问题，或者正式要引入某种来自行业外部的新技术和商业力量来解决当前普遍需要解决的行业性困难。也就是说，一个解决方案要么解决的是一个本行业的新问题，要么是引入了原本属于其他领域的技术而成为两个领域的重叠区域。这些时候，一般性的专家观点对你有多大的帮助就很难说了。总之，无论何时，在征求专家的意见的时候都要同时运用自己的大脑：要随时考虑专家的职业立场、个人背景、利益相关性等等所产生的意见的盲区，而切不可盲目接受。实际上，当你为某个问题提供了客户普遍认可的解决方案后，可能只有你才配称为这个问题的“领域专家”。

还有就是，不要试图请解决方案要服务的目标领域的专家回答你自己领域的问题。在理解客户需求的时候，难免会令我们立刻陷入对如何构建技术方案来满足这个需求的迷惑中，但请将这个迷惑放在心里或者记在笔记本上日后处理。因为这些都不是现在就要和客户或者目标领域专家讨论的事项，而是体现我们自己的专业能力的地方。

小案例

记得一次在与客户讨论其能源管理系统该如何构建的时候，当客户中负责能源管理的工程师说：“我们公司的水、电、热蒸汽的账单结算日是不同，分别是每月的20、28和30日。所以，在计算每月的能源消费的时候，要注意统一折算到每个自然月。”这时项目经理问：“对于折算，贵公司是希望采用按每天平摊的方式么？或者有其他的方法？”客户显然对这个问题陷入沉思，但是他们知道这时他们必须回答的。不过有时候客户也会说：“也许你们比我们更有经验，或者麻烦你们在方案里做一个建议吧。”事情到这里还没有跑偏，但是突然我方的一位工程师开始大声抱怨：“如果这样，我数据库的复杂性就会增加。或者你们能建议我要怎么设定我的表结构呢？”客户方的能源管理工程师此事已经完全不知道要怎么应对了。

四、问卷调查

调查问卷其实可以视为直接干系人访谈的一种格式化的模式，但是越来越多的人开始在问卷中采取没有标准答案的开放式问题。在现实中我们可能不得不做出某种妥协：提供有限可选项的标准化问题用于我们已经自信梳理出来全部（或者绝大多数）潜在答案的问题，而开放性问题留给那些我们还不甚理解的问题。开放性问题在需求采集过程中需要被采访者花费较多的时间来回答，所以有时不得不付出一些沟通代价，比如一个小礼物；另外后期的需求整理也需要更多的逻辑分析技巧。

对问卷调查的评价可谓毁誉参半，而且可以说这其中的“毁”的成分在近年来有变多的趋势。但事实上，很多时髦的调研方式中都或多或少包含问卷调查的隐含模式，只不过这些新方式的提出问题的方式更加隐晦和自然，从而更可能获得有深度的答案。

五、场景观察

对于企业流程改进类的问题，场景观察室一种非常有效的方式，尤其当你缺乏背景知识而陷入一片迷茫的时候。另一种特别适合场景观察的情况，就是客户感觉其自身某处存在问题，但是却无法明确提出。这在离散制造业中其实非常常见，也正是为何一些管理咨询公司可以在企业管理信息化的领域十分活跃的原因：咨询公司的典型模式是从企业流程的理解和优化切入，在优化后的生产流程得到客户的认可后，再给出配套的信息化系统的设计，最后安排软硬件工程师搭建新的系统或改建既有的系统以实现最终的交付。

场景观察的第一步仍然是需要做一点基于公开信息的调研，从而能给自己多一点在观察中发现问题的启示。但是可能一开始未必深刻。然后作为一名观察员记录和梳理客户的日常活动流程和特点，关注其信息交流模式，建立既有流程的模型。但是更快的方法是，需求采集者是作为客户团队的见习员工而不是观察员，直接参与到客户团队的日常工作中去。这么做的一个附加好处就是建立了采集者和客户团队成员之间的人际关系纽带，从而可以为捕捉更细致的信息创造条件。这种方式在等级观念较强的企业或者政府机关中有特别好的效果，因为在那样的局部环境下，正式的会谈中下属可能并不敢明确表明自己的观点——对问题的明确表述可能会被同事和上级主管视作某种不满的发泄和抱怨，而不是建设性的工作态度。

在现代有各种记录设备的条件下，场景观察可以提供非常丰富的原始资料以供后期的分析。但也可能会造成观察者被淹没在场景中、被细致末节的事情误导而忘记了场景所处的大环境的危险。有时候场景观察给观察者的印象太过深刻，以至于观察者会特别坚持观察中所获得的信息所得到的推论，但是忘记了整个企业、整个行业甚至国家经济与社会面临的变化。这样的结果必然是得到一个在最初看起来非常有效的方案设计，在几个月内就可能瞬间就瓦解了。这种在方案企划阶段的缺乏前瞻性，也是部分解决方案不得不面临持续改进的原因之一。

7.1.1.2   需求归档
建议将获取的需求整理成文档，一方面防止自己在未来的工作中遗漏，另一方面也方便传递给其他同事进行深入的分析。

首先建议要保留所有的原始材料。需求获取过程中的原始材料的形式多样：书籍或书籍摘要、简报、网页存档、手写的笔记、问卷调查的原件、录音、录像、照片等等。一个原则就是，在随后的整理分类中，尽量将这些原始材料保持原样而不是销毁。虽然这些原始资料可能并不值得你花费时间去编目整理，只要找个文件袋放好或者将数字化形式的文件存放在某个文件夹中即可，但是保存原始资料永远是个值得称道的好习惯。这么做的主要原因在于：虽然在接下来的过程中我们需要将这些原始材料进行整理消化，但是要注意，人们的整理工作永远只是基于当前对问题的理解而进行的；随着我们进一步的分析和着手开始设计方案，甚至在后期的实现和运行中，随着我们逐渐成为方案领域的专家，我们会不断加深我们对原始材料的理解，从而发现最初的原始材料中在一开始被我们忽略的内涵。

其次开始将原始资料做一定的整理。这种整理有初步分析的意味，但还是没到方案的详细设计那么深刻。在这个阶段，实际上笔者建议在整理过程中尽量客观梳理所收集到的信息，而不要把自己在梳理过程中不自主的对解决方案的灵光乍现掺杂在整理文档中。你可以将这些灵感记录在一个笔记本中以备后期在方案设计中使用，但记录在需求整理的材料中却很可能是个坏主意：这有可能因为你对自己的这个灵光乍现的思路的执着而扭曲了客观事实，甚至将后续加入的其他团队成员都“带到阴沟里去”。

需求文档的形式灵活多样，具体的形式其实是要看具体的信息采集过程。为了方便信息的传递和后期的分析，可以尽量将原始文件数字化、量化、甚至做成电子表格的形式。要恪守的两个原则就是：整理的目的是为了方便后续的分析和引用，而整理的方法就是尽量将原始资料转换成方便分析和引用的方式，但同时避免丢失任何有价值的信息。

如果你做了某种问卷调查，对问卷的答案做一个电子表格，甚至提供一点统计是不错的方式。如果这个问卷的问题是开放性问题，即并不是在有限的选择中选取，整理的过程则需要特别的小心和技巧。此时建议您仔细阅读每个开放性问题，然后试图识别这些开放性问题的答案中所展现的规律，从而进行进一步的分类。如果这些规律相当明显但是并没有被所有的被调查者在答案中反映出来，也许你应该尽快组织另一场针对这些新发现的规律的调研（可能是另一场问卷调查）。如果新的调研已经在资源层面不可能，建议在尽量分类整理后，用一个“备注”栏将那些可能值得特别关注的回答摘抄出来。

对于照片、录音、录像这些资料，其信息量往往很大，我们需要一种“无损压缩”甚至“有损压缩”的方式。将在这些资料中观察到的现象用文字尽量客观地记录下来。

无论是什么样的原始资料，在整理汇总过程都尽量分类和量化。分类和量化实际上是一种“有损压缩”方式，因为在这个过程中必然会损失一定的个性化信息。这个有损压缩是否会丧失过多的有效信息，实际上有很大程度上依赖于整理者对领域知识的掌握程度甚至是直觉，甚至有一点“艺术”的成分，需要经常的练习和思考才能增进和保持这样的能力。

在规模较大的公司，或者某些自以为已经不会发生任何改变的所谓传统行业中，一个常见的现象就是企业会制定某种信息收集的表格来发现需求。

7.1.2   需求分析
需求分析的目的是得到对解决方案的功能描述。有时被称为市场需求文档（MRD，Market Requirement
Description）或者产品需求文档（PRD，Product Requirement
Description）。实际上，需求分析是整个解决方案的功能设计工作，分析的结果就应该已经决定了方案的交付物形态和存在的边界。如果没有这样的功能设计作为交付物，需求分析就仿佛只是得到了一堆没有得到答案的问题。如果是需求的获取是“什么问题值得我去解决”，需求分析就相当于先回答“问题的实质是什么”，然后计划一下“我该如何去解决”。

7.1.2.1   分析的框架：宏观与微观

在需求分析的过程中，针对企业客户的宏观和微观的关系是一个需要方法和经验来把握的地方。对于企业，在管理学中用的波特五力和PEST方法，是典型的对其所处的生存环境的分析框架。而企业的微观分析的维度，常用的有QCDML维度，即：
Q-品质（安全性、稳定性、可靠性）
C-成本/价格
D/D-产量/效率/交付能力
D/L-产品研发/技术
M-人才/设备/物/方法/测量
S-销售/服务

另外一个很重要的常用框架就是SWOT分析。

以上这些分析的框架在常见的管理学书籍中都要，此处不再赘述。需要提醒的是，凡事都有两面性：任何框架对于头脑中缺乏思路的人而言可以起到很好的提示作用，但是对于有一定经验的人而言，却可能无意中让你失去了某些特殊的视角。

参考和使用这些框架的好处在于，框架不仅会提醒你在采集需求信息的时候不要忘记有关的维度，防止你犯对某一维度过问重视的错误，也可以为你提供一个检验迁移阶段需求获取过程中工作的完整性。你可以把这些框架作为一个检查清单，然后对照下看看是否遗漏那一方面信息的收集和思考。利用这种框架的提醒不是说你应该事务巨细地关注所有的事情，更不是说你要在随后的文档中牵强附会地非要把两件没那么大关联的事情扯在一起。作为需求的收集者，你永远有自己判断的权力。

一个例子在中国特别常见：很多企业家过分迷信政府政策的主导能力。当被问到为何开始某个业务的时候，或者在向其客户推荐某个解决方案的时候，会特别强调政府的政策导向。这种多少带有一定的投机主义的做法，仅适合一些短期的项目型的解决方案，作为长期的业务和需要较大前期投入的产品，把政府导向作为市场调研的压倒性因素是非常危险的。虽然政府是不可忽视的力量，但也永远只是不可忽视的力量之一。

7.1.2.2   分析的方法

为什么要先回答“问题的实质”呢？因为需求获取中收集到的信息，本身可能只是一个表象，而不是真正要回答和解决的问题。这就好比你见到一个皮肤发黑的人，问题不是“皮肤黑（表皮层天生色素较多）”，而可能是日光浴、中毒或者其他别的什么诱因，不同的诱因首先决定了这个表象是否是值得担忧而要消除的，然后才是如何消除。
常见的分析方法有：

一、递进推演

递进推演就是以说获取的需求信息为基础，不断总结、不断归纳，不断寻找其中的各种内在逻辑，从而激发自己和团队的灵感，找出解决方案。这里我们可以简单讲两个比较实用的工具，即思维导图（Mindmap）和头脑风暴（Brain
Strom）。

思维导图由Tony
Buzan发明，最初作为学习工具，后来逐渐流行于各种企业培训，尤其是在信息技术和互联网领域。既然其发明者声称其可以表征和模仿人类大脑思维的过程，那么出现这样的情况也就不足为奇：似乎什么事情都可以采取思维导图的方式，从做读书笔记到整理创意。当Apple公司推出了划时代的iPhone智能手机之后，思维导图软件也第一时间出现在其应用商店中。

在利用思维导图整理你的思路的时候，一般的主张是采用一张尽可能大的纸张（思维导图软件的制作者们声称，计算机和手机的屏幕尺寸不是问题，因为你可以上下左右地移动从而获得实际上是无限的纸张大小。信不信由你吧。）然后将需要讨论的核心议题的关键词写在当中，并且随着你的思考，把围绕这个关键词出现的新的关键词写在其周围，并用线连接。这些线就像神经一样，连接的都是有关联的关键词。慢慢地你就产生了分类整理的欲望，此时你可能需要重新拿一张纸来重新开始画。（如果用软件，就是花一点时间重新编辑一下。）画面上所有的表达尽量生动、简洁、充满色彩、尽量用图形，以及任何可以刺激你的方式。慢慢地，你开始看出主要逻辑之间的横向的关联性，所以还会加入一些虚线来表达各种关联性。

现在回到需求分析这个我们正在面临的任务。相信你已经明白了，你现在不缺少关键词，因为你已经进行了需求的采集工作。现在你可以尽情地利用思维导图来整理你获取的资料了。你可以先将已经初步整理的原始资料做进一步的分类整理，然后开始在图上进行下一步的推理，然后是建立横向的联系，进一步加深自己的洞察力。

还记得刚刚讲过的那些分析的框架么？没错，围绕你的核心问题关键词的第一层关键词也许就是来自那些框架。而类似SWOT之类的综合考虑企业战略的框架也正可以建立跨越各由第一层关键词引发的分支的新的关联。

思维导图的基本方式并不难，但是要做得好还是要靠不断的练习来养成勤于思考的习惯。另一个值得推荐的方法是，一个小组而不是一个人来完成关于一个解决方案的思维导图。与该方案有关的工作小组所有成员在一起，每个参会的人在进入会场之前已经获得了之前获得的需求信息的整理文档，甚至已经经历一场有负责需求获取的同事主持的汇报会。然后大家在主持人的带领下，一边讨论，一边绘制思维导图。

头脑风暴的方式是必须基于一个小组的集体会议的。在主持人的带领下，大家自由发挥自己的创意给出见解，并将自己的想法写在若干张纸条上。为了防止思路的过度发散而偏离重点，每个人的纸条总数可能是有上限的——也就是说，强迫每个人写出他自己认为的最重要的几个见解。然后大家将每个人的纸条拿出来评审，合并同类项，去掉公认为不可行的。然后进行一轮投票或者就此次发现的新的问题再做一次头脑风暴迭代。在做头脑风暴的时候，主管最好是主持人，并且不要发表任何可能压制同事意见的评判。

同样地，进行头脑风暴之前，也应该做好会议准备，即每个人参会者都必须得到一份需求信息汇总文档，并有充分的时间消化。

二、场景构建

场景构建的方法是在试图搭建一个构成目标用户群体的所有角色所活动的一个完整的场景，以供进行思维试验，并从中来理解现有场景存在的问题，推演解决方案对这个场景所带来的全方位的影响从而完成解决方案从构建到评估的全过程。

场景构建的关键词是思维试验，所以你之前收集到的那些信息其实是搭建最初的思维试验原型的钢筋砖瓦泥灰这样的建筑材料。而这个原型在你的思维中搭建成功之后，我们就可以假象我们成为其中的某个角色，从而体会这个角色感受。如果这是一个涉及多类角色的场景，我们可能还要学会切换不同的角色，身兼数职。或者，利用团队的力量，由不同的人扮演不同的角色来利用场景所提供的故事脚本扮演这个场景。

在利用对现状的理解逐渐进入角色之后，作为画外音的方案主持人可能说，如果我们加入了这样一个改变，大家又会怎样。于是按照新的剧情大家继续推演。推演的过程最好可以利用录像设备记录下来，以备事后集体讨论和分析，从而不要让团队被不得不停下来的记录而把自己从刚刚进入的角色中拉出来。

场景构建的技巧掌握起来难度较大，但就其威力而言，是值得花精力去学习和实践的。

7.1.3   文档编制
7.1.3.1   文档的名称

需求分析的结果就是要编制出市场需求文档或者产品需求文档。在实际应用中有的企业将对采集到的需求信息的原始材料的整理文档（可能有时还要添加一定的分析结果）称为市场需求文档；而将对解决方案的设计，特别是这个解决方案最终是一个产品的时候，称为产品需求文档。有时候索性简化，只有产品需求文档最为这一阶段的最终工作成果。也有的理解认为，如果公司的商业模式以项目为主，则称之为市场需求文档，如果以产品为主，则称之为产品需求文档。这个理解的理由是，项目一般是为其客户单独打造的，所以基本上客户的需求不用经过太多的分析和设计，只要比较直接的记录和整理即可，所以这一阶段的工作结果也就基本上是对需求的原始材料的整理。而产品为主要商业模式的公司则不尽然，他们需要采集来自多个客户或个人用户的需求，然后做较为深入的消化才能设计出一个满足大多数目标市场个体的一个解决方案。显然后者是需要更深入的分析和打磨的，所以后者采用产品描述文档。

为客户定制暗含了一个潜在危险：为客户定制打造对任何公司都是一项耗费成本的工作，因为在产品化的过程中，一些研发和管理费用会因为产品化的复制而被多个用户分摊，从而可以大大降低用在每个客户身上的成本，即所谓产品的规模效应。然而，如果你认为为客户定制就意味着放弃产品化的模块重用和成本分摊的话，就可能最后陷入营业额高涨但利润增长很慢的窘境。更不用说，如果放弃了产品化中那种对质量的追求，加上太多个性化的模块，最后容易导致售后维护陷入极端困难的境地，你讲项目成果交付给客户时让你兴奋不已的毛利润很快就在费时费力的售后服务中烟消云散了。这是为什么为了打造持续的业务，即便是在具体客户定制方案，我们也应该尽量寻找可产品化的局部模块的原因。

总之，文档的名称并不重要，更不要被文档的名称所隐含的某种寓意而迷惑。任何时候，编制文档的最高宗旨永远是：讲得明白。

7.1.3.2   文档提纲
你就职的公司可能有需求分析的模板，网上有很多类似的免费分享可以利用。如果你仔细比对，就会发现其实这些文档模板都大同小异。

XXX项目需求分析
业务背景
讲述业务需求的来源、目标客户、需要解决的问题的最初想法等。
行业分析

讲述当前行业中对此类问题的解决方案的现状：都有哪些公司或者团体活跃在这个领域，各自扮演神了角色，他们提供了什么解决方案，市场对他们所提供的反应如何。更重要地，你的团队对这些解决方案的优缺点的评价如何。
客户需求
即将之前获取的用户需求的原始材料整理消化后放在这里。
需求分析
这一段是真正的分析和推理过程。将你和你的团队对以上所欲有那些信息，按照一定的框架，采用一定的方法，消化后以某种概率相信用户就是需要怎样的功能。
功能设计
将上面已经分析得出的功能详细描述在这里。
非功能性要求

这一段实际上很容易被忽略。经常看到仅仅是应景一般淡淡写上几笔诸如“保障数据和网络安全、注意实施成本”之类的话。比较好方法是，要重点突出那些对这个解决方案的实现有明确意义的要求。那些行业中的一般规则就没有必要再写了，或者简介明了地写出“数据安全性应符合国家某某标准”即可。

需求文档的措辞要尽可能地明确可操作，少用“高、底、多、少”之类的形容词，除非这些词语在特定的领域已经有了约定俗成的定义。这么做不仅仅是要在余下的工作中保证准确传达其含义，还有一个重要的法律意义。需求文档很可能成为合同的一部分，一般成为技术合同或者合同的技术附件，这样而言，那些模糊而容易产生歧义的形容词就成了潜在的风险。

7.1.3.3   常用工具
除了上面的模板提纲，一些具体的表述方式也是常见的工具。

一、   图表

最常用的是大家都熟悉的流程图，其中分部门的流程图对于连接多个角色的应用更加清晰明了。虽然UML体系的一些列图表被设计来为复杂的应用建模，但是并不是其中每种图表都在需求分析中被同等地重视。用例图是最常用的一种，然后是活动图和交互图。一些特别技术性的解决方案可能会用到状态图。UML的最大的诟病就是，太过理论化以至于很多时候会让你的客户感到难以理解，从而影响你的团队和客户的交流。更糟糕的是，偶尔极端的情况下，有些客户会认为这种他看不太懂的图表本应该是你自己需要处理的东西，从而因为你要拿这个图表来和他讨论而低估你的技术能力。

二、   产品原型

包括产品效果图，操作界面的框线草图，描述交互模式的文档等。我们可能已经越来越习惯于原型了：建筑师给客户的效果图和按比例的模型，甚至连我们购买尚未完工交付的公寓的时候也能看到这样的模型；饭店前台的每道菜的蜡质模型。软件行业最初喜欢给客户预先设计几个典型的界面，现在已经发展处利用一个很复杂的原型工具来几乎模仿出整个软件的操作过程——有些工具在勤奋的产品经理的手中会把软件模仿得如此逼真，即所谓“全尺寸模型”，已经会让某些粗心的客户认为软件已经濒于完成了。而且，一些原型工具的功能如此复杂，简直将自身变成了图形化编程工具。常用的工具包括Microsoft的Visio，主要是做界面框线图，而FLASH、Auxure和一些基于HTML5的工具主要用于搭建逼真的原型。中国国产的软件也有一些。

三、   场景描述

一个场景的描述包括时间、地点、人物、事件和各角色之间的连接方式。和构建场景和推演的方法类似，描述一个场景也可以借鉴剧本的创作。先要流出这个元素，然后再分幕描述在这个场景下可能的不同“剧情”——也就是各类角色利用方案的功能而形成的新的动作，尤其是角色之间的互动，这一点对于连接多种角色的流程类和多边平台（存在不同用户群体的平台）中尤其重要。

7.1.4   需求评审

需求评审总地来说可以分为内部评审和外部评审。这里的内部和外部的界限在哪里，可能会让人迷惑。笔者主张的定义是，凡是在最终用户的评审之前的任何评审都称为内部评审。而外部评审就仅指最终用户的评审。所以，对于同一个公司内部需求的解决方案，方案最终使用的部门的评审其实应该视为外部评审。
常用的评审方法有：

一、文档回顾

这是内部评审主要采用的模式，但是常见的客户回访会议中也是以文档回顾为主。团队，包括团队的外部主管一起回到最初的需求整理文档，然后逐条对照是否被功能设计中的某一条或某几条满足了、满足得好不好、是否有更好的改进。文档回顾可以采用审批流程，但是大家坐在一起的评审会效果会更好。

内部的文档回顾可以不做特别的准备，但是在客户回访会议中最好再编制一套幻灯片，并为每个与会者准备一份需求整理文档和需求分析文档。你应注意对内对外的文件在措辞上的不同。

小案例

一家建筑智能化系统集成商正在为某个学校的新教学楼的弱电工程准备方案。这个方案除了正常的需求，还有一个资金层面的意图：当地政府对可为学生提供现场试验的设施可以给予一定的补助，而这个学校由于资金的紧张很希望能够拿到这笔补贴。学者们的表述是隐晦的，但实际上却是压倒性的。这家集成商的项目团队敏感地捕捉到了这一点，所以在内部的文件中特别突出地描述了为这一意图的设计。但是在客户（学校）面前汇报方案的时候，这个需求不会被说成“顺利获得政府的补贴”，而是“充分考虑学生实习的需要”。

二、原型检测

无论对内部和外部的检验都很有效，但是对于内部评审似乎成本有些过高，也未必及时。即利用搭建的原型来回顾和检验是否符合目标用户的需求。有时我们可以将原型直接展示给目标用户，然后听取他们的反馈。因为是原型，很多时候还不能直接体验，所以在展示的过程中讲解员的表达能力很重要。也可以使用视频录像的方式，利用一名同事扮演客户，大家将该同事使用原型工作的过程录制剪辑成一个短片。这名扮演客户的同事，最理想的人选是对该项目有一定了解但是在设计过程中并未深度介入的人，比如该项目的销售、项目组的直接主管，或者合适的该领域外部专家。如果不甚方便，也可以将典型使用情节拍成照片或者配合场景描述中的脚本来展示。

原型检验可以帮助人们检验一些不那么好想象的细节，但是对于不适合形象化表述的技术标准类需求是不适合的。所以，原型检验最好是配合文档审查使用。

7.1.5   其他话题
7.1.5.1   谁是用户

我们一般认为，那些为客户定制的项目很容易识别用户是谁，但真的是这样么？对于一个企业客户，实际上你要面对的不是一个人，或者一个虚拟的企业法人，而是一群有不同利益诉求的人。一套旨在增进企业运转效率的制造执行系统（MES）或者企业资源系统（ERP），被管理者和管理者之间就可能存在不同的理解。在这样的系统中，普通员工往往是每天最频繁的使用者，但是主导系统需求提出和认可的却往往是主管们。如果不能平衡地处理各自的诉求，就可能出现系统功能过度围绕管理者的需求设计，而需要输入数据和通过系统互相协作的基层员工的体验是被忽略了。这很可能导致员工们花费太多的时间“服务”于这个新上线的系统，而不是感到被系统所服务。最后也就导致基层员工对系统的上线怨声载道，甚至或明或暗地拒绝配合。最后当回顾和评价这个系统的作用时，能够得到什么样的评价就可想而知了。这也是为什么在某些企业中每次更换主管经理时就容易重新改造系统，因为每一任新上任的主管在聆听员工的意见时一定会得到很多关于系统的抱怨，于是便开始以针对系统的整改来取悦大家或表明自己的工作成就——而这些整改可能原本就不该发生。

另一类被忽视的用户是二次开发者。每个系统或者产品都免不了被改建或扩建，此时它就面临者新的开发人员这类特殊的用户。我们可以看到，最近出现的各种物联网平台服务商，实际上他们百般强调的卖点正式面向二次开发者的友好。项目型的解决方案实际上存在同样的问题。清晰的架构和文档给未来的维护者带来工作的便利，而这种便利就意味着更低的维护成本和更快的反应速度。

7.1.5.2   需求分析者的素养
虽然有很多讲解需求分析的教科书，但是不能否认这项工作中存在很大的艺术的成分。作为半个艺术家，为了做好这项工作你需要在平时就培养自己的工作素养。

首先，你必须在客观中保持自我。既要在信息采集的过程中保持客观的精神，也不能放弃自身对现实的思考。即便是对一个问题有着同样的见解，不同的人给出的解决方案也会不同。那么哪一个是最优，必须要秉承客观的角度去判断，同时对自己的创意又足够的自信——这种自信至少要支撑到的确被各种后期的论证证明不适用为止，而不是稍一遇到质疑就放弃。

其次，要磨练自己抓住重点的能力。在这个过程中你会遇到很多信息，有些也特别有趣，但有趣不等于是关键问题。你必须在工作中建立起一套筛选重要问题的标准和思考框架，或者能快速识别关键客户的平角标准和思考框架。

最后，要学会有效地沟通。学会在沟通中掌握移情作用是最好的手段，这一点在理解客户的关键诉求非常重要。在各种文档和演讲中要紧扣主题、反复强调和再现它。沟通的表达要精炼在精炼，可以参照很多咨询公司采取的所谓“电梯检验”，即：假设你和客户的主管只有乘电梯下楼的30秒时间，你要怎么有效利用这么短的时间将重点传递给他？当然，完整的功能实际是不可能用30秒浏览并理解透彻的，但是关键信息的获取过程可以，分析后的关键结论和功能设计的终点可以。可视化手段一般来说比文字更容易给人以直观的感受，而当今多媒体科技和各种图标软件的确也提供了这方面的便利，要充分利用。还有一点就是沟通的时机问题。对于吹毛求疵的客户，也许结论性的沟通放得晚一点，待你基本落实了每个细节再进行可能会更有效，而有的客户却喜欢随时了解您的进展而随时可以决定是否跳进来和你一起工作。你对客户对沟通的偏好越早识别出来是越好的。

7.1.5.3   对方案企划过程的管理

首先的建议是，不过度流程化，反对模板主义。这两点是相互关联的，因为流程化的过程中往往引入标准化模板，以便让批准流程也标准起来。标准化的模板可能将批准者在审批过程中下意识地关注模板本身被填写的完整性，而非模板中的内容。而填写者在填写模板的时候，也容易下意识地关注模板本身的完成情况而不是问题被揭示的程度。

让评审者成为责任人。评审者对方案的成败负有一定的职业风险，有助于评审者建立对评审工作的责任心和荣誉感，从而积极参与到对文档内容的主动理解中来。

上一篇：工业物联网：6 商业模式 <https://blog.csdn.net/kimbo/article/details/82949282>

下一篇：工业物联网：7 项目生命周期管理（2） <https://blog.csdn.net/kimbo/article/details/82949738>

热门工具换一换