如何在erp实施上尽快入门

序

现在的中国，做软件咨询这行业的人已经烂大街了。

很多人从做技术转过来，SAP功能玩得很熟。

有的人从企业转去咨询公司，原先的业务很精通。

也有些人一毕业就能进咨询公司，一个项目接一个项目。

所有这些人，在这个圈子里混的人，对于怎么做项目，大多都能侃两句，说个1，2，3

什么Blueprint啦，Build啦，Testing啦，这些实施过程中的阶段，大家都说得出，都知道。

可是，大家真的都了解怎么做项目吗？

真的知道一个Deployment需要做的事有哪些吗？

真的知道一个Program中各个Deployment之间的联系吗？

真的知道为什么要这样做吗？

一，从最细节做起

我刚做项目的时候，是一个外企的Roll Out，PM是马来西亚人。

当时每个Team要做Status Report，Status Report是用PPT做的，有专门的模板

每周开会，大家在一起一个一个Team Review

PM在开会的时候，会盯住Report的格式。

增加一个页面不能用Ctrl C + Ctrl V，一定要在PPT里insert一个页面，这样才能最完整地Copy模板

每个页面的每个文本框的字体大小要符合模板

分行，分段，页数，日期格式，要符合模板

Report的内容里，一定要有准确的数字，本周计划完成几个，实际完成几个，绝对不能用百分比来糊弄过去要做的任务，要有PIC（Person in Charge），Target Day。

在描述一个事的时候，不能用“我们”“他们”之类的词。“我们”是谁？“他们”又是谁？

最后，还要写好revision history。

当时我们，特别是中国的同事，觉得好麻烦啊。花那么多时间看这些细节做什么。

字体不一样又不会有事。每个工作的完成情况，要精确到具体数字，统计起来也很花时间

不过，久而久之也就习惯了。

若干年以后，当我看到另一个国企项目的Status Report。

那个国企项目的Status Report，也有模板，但是很简单

而具体的报表内容，完全没有上面我提到的要求

结果就是，我完全看不懂。

另外，不同的Team的report要汇总在一起，如果字体不一样，换页的时候你会很明显看到差别。

Status Report只是一个小东西。但是对于细节的认真却是非常重要的。

任何一件事，谁去做，谁来review，怎么做，什么时候完成。。。

你如果不讲清楚，别人也不会知道，结果肯定是事情做不好，要不就Delay。

所以，要做好一个项目，首先请认真对待细节。

二，Logistics

这里的Logistic是指后勤，是项目中为大家提供的生活工作服务。

为什么要说这个呢？

因为作为一个Deployment，最开始的事情，是PM要解决Logistic方面的问题。

现在做一个项目，成员大多是从不同地方来的。那么住宿应该怎么安排？

通常的，PM要找几家当地的宾馆谈谈价格，有时客户那里也拿得到协议价。

住的地方不能离客户太远，上下班会花很多时间，打车费用也贵

住的地方不能离市区太远，顾问出差不能与世隔绝，也要考虑生活便利

住的地方的房型怎么样，是1个人一套还是2个人一套

2个人的话，人员怎么安排？不是随便2个男人就可以安排在一起的。

要考虑这2个人是否能相处。

往返机场，往返客户那里，找什么样的交通方式？

找固定的出租车司机还是随便在马路上打车？

要知道，安全是第一位的！

吃饭的话，Team Member有没有忌口，有没有国外的习惯

在客户那里，办公在什么地方，

一个项目20个人左右，加上Key User，怎么坐？

一般会说一个Team做一起，那么Team和Team之间的交流呢？

FI和CO要近一些，PP最好和MM近一些

顾问和Key User最好隔着坐，不要顾问只管自己，这样方便沟通

办公的地方，出入证明，电话，传真，打印机，复印机，饮水机，网络，空调，投影机，会议室

等等这些资源都要安排好。

把Team Member的名字贴在位子上方便别人找到

做一个通讯录，最好打印出来发给每个人

......

其实要说清楚Logistic的事情，实在是太多了。

可是你知道吗，这是PM要负责的事情

因为这时候项目还没有开始，人员还没来。

而且很多牵涉到费用，PM需要控制成本。

当然有的时候PM会找人帮忙，等项目开始以后让某个人来管。

但是，这始终是作为一个Deployment开始所要做的事

也许很多PM做这个比较随便，甚至很舍得花钱。

但我想说的是，事情做得好不好，关键还是在细节。

安排的资源有没有考虑别人的感受想法。

要考虑如何才能大家不用抱怨环境差，开心地工作。

三，Global Template

让我以一个Global的Program为例子吧。

什么是Template

通常的，在一个跨国企业实施SAP的时候，要面对的是不同国家，不同工厂

不同分公司业务也不一样，有些是生产型的工厂，有些是贸易公司

那么作为跨国企业，一般都是要把业务整合在一个系统里。

在SAP里就是1个Client，里面分多个Company Code

Company Code就是单独的分公司

所以在开始真正实施SAP之前，就要考虑整个企业（Client）的架构

包括统一的业务流程，统一的解决方案，统一的数据格式

这样一些统一的东西，就叫Template

我们自己的说法，也叫Global Template

等设计完了这些之后，再去一个一个工厂实施

在工厂实施过程中，肯定会碰到和Template不一样的需求，这时候也可以再修改Template.

Template包括哪些内容

首先是组织结构

要控制这样一个Template，就要有一个专门的Team来管理，GT Team (Global Template Team)

这个Team里每个人是一方面的专家，比如FI，MM。这些Team Member面对的客户的人，是整个企业这一级别的BPO（Business Process Owner），比如CFO。

在每个Deployment实施过程中，Deployment Team碰到的需要更改Template的需求，都要报告给GT Team，由GT Team负责协调其他Deployment，看是否能做这样一个修改

比如说某个Deployment想在物料主数据里用某个字段来放一些参考信息。

可不可以呢？这就要考虑，这个字段在SAP的标准功能的用途是什么，

物料主数据是被所有工厂都通用的，其他Deployment实施的时候会否用这个字段

这个字段在系统的报表里会不会被用到

......

Template的重点是Blueprint Design

物料主数据的命名规则是什么？

什么物料用什么物料类型？

集团的科目怎么定义？

Cost Center，Profit Center，Product Hierarchy

要不要用Material Ledger

要不要用Split Valuation

Document Type用哪些？Number Range是多少？

......

统一的Process

比如采购申请，谁提申请，谁批准

比如生产订单发料，是Issue to Order，还是Backflush，还是都可以

......

统一的权限控制

设置Common Roles，Deployment只要Copy 这些 Roles就可以了

......

Template也包括程序开发

有些report是整个企业都会用到的，那么就在Template里做好

到Deployment时期只要用就可以了

......

还有Document Template

所有的文档的格式，Status Report，Data Conversion Template，To Be Process，

当然包括我一开始提到的字体大小，分行分段等等，都是在Template里定义

怎么做一个Template

很遗憾，我没有做过Template，所以这部分我说得不仔细

做Template也是个单独的项目

一般在Program开始后，在Deployment开始前

企业会召集很多人，有顾问有用户，用户可能来自各个工厂

过程也象做项目一样，业务调研，蓝图设计，系统搭建，文档准备等等

为什么要做Template

很难想象，如果没有Template，怎么为企业实施一个整合的SAP系统

Template的好不好，还是取决于细节

当我一开始看到Template所做的文档，我很惊讶，居然把项目中要用的文档都做得那么详细

很多时候，我们只要Copy过来，改几个字就可以用了

看着Template，就可以很轻松地去工厂实施。

所以，一个好的，详细的Template，是整个Program成功的前提

四，Capture Local Input

有了Template，接下来就是去分公司/工厂做Deployment了

前面提到，不同的工厂业务不一样，Template不一定完全适用

所以在开始Deployment的第一个阶段就是Capture Local Input，中文来说就是收集当地的需求

那么怎么来收集需求呢？

首先要准备介绍资料。介绍SAP系统，介绍Template的设计

介绍资料一般用PPT做，用于在Workshop上跟用户讲解

其中的重点是，要用用户看的懂得方式去介绍。

我看到过一些人写的资料，包括培训材料，完全是走技术路线

说说用到哪些功能，T-code怎么样，在系统中产生什么Document，就结束了

可是，另外的，可以写一些：

1.名词解释

2.企业有什么Policy，来让我们决定Template的设计

3.原来的业务流程是什么，Template会改变什么，有什么Benefit

4.对于权限有什么影响，对应于业务上的什么部门的什么岗位

要记住我们在Template的基础上做实施，就是要做好功课，才去工厂Capture Local Input

介绍资料之后，还要有一个Question List

哪些物料类型会用到？

不能直接问有没有产成品，原材料。

可以问，有没有Packaging Material，比如Chip Board，Wood Pallets，Wood Containers

有没有Petrochemicals，比如Fuels，Industrial Chemicals，Lubricant

......

哪些Payment Term会用到？

比如见票30天付款，见票60天付款

......

在Template的基础上，就不要问很基础的问题了，要跟实际业务相关，能直接帮助之后系统设计的问题

在Capture Local Input阶段，通常会召集不同部门用户来开Workshop

召集的用户人员，范围，需要仔细研究

一个用户不能同时参加MM和FI的2个Session。所以有必要的话时间要错开

有的Workshop，需要BPO参加，要事先打好招呼发invitation

有的Workshop需要不同Function Team一起讨论，称为Integration Session

经过Workshop，要把Local Inputs记录下来，成为Local Inputs List

在这个List里，当然的，要包括

1.简短的一句话来描述这个Inputs

2.详细介绍

3.谁提出来的

4.提出的日期

5.对应的BPO是谁

6.分类，这个每个项目可能不同定义

7.需求类型，这是个Config相关的需求，还是Data Conversin相关的需求

8.是否影响Global Template

9.Priority，这个Priority有专门的定义，不是用户说High就是High的

10.谁负责跟踪这个需求

11.可能的解决方案

12.状态，Open还是Closed

这里要提到的是，记录的需求多没关系，只要跟踪好，稍后跟用户确认，状态Closed掉就可以了

就怕2种用户，说话太多和说话太少

这阶段嘛，项目经验还是很重要的。很多需求在Workshop时就可以砍掉了

另外，报表的需求也要在这阶段收集

重点是在这阶段就要做rationalization，合理化。

要知道，开发的需求搞得越多越烦，一定要砍掉，砍掉，砍掉。

最后，PM需要每天开会，Review Status

今天收集了多少local inputs, High的多少

不断地跟踪状态。

结束的时候，Local input list要跟BPO确认，作为下一阶段Blueprint Design的依据

五，Blueprint Design

Blueprint Design阶段，主要的时间在针对Local Input来讨论Solution

也就是说，收集到需求，都要在这一阶段找到解决方案

其中，有3个文档是最重要的

它们是Blueprint，To Be Process和Data Conversion Approach。

什么是Blueprint？

有一些比较概念性的介绍，比如这是系统的设计，解决方案....

实际的，这是一系列Word文档

每个文档对应一个模块，里面详细介绍各个功能设计

文档里要包括对于这一功能的需求介绍，详细的需求分析和解决方案，对于这一个Deployment的特别的结论

比如说，Physical Inventory 库存盘点

1.用户的需求是什么？保证库存准确率？和财务的Balance一致？

2.详细的需求呢？库存准确率是按Plant level还是Storage Location level？要不要用Cycle Count？

3.解决方案呢？A, B, C分类怎么定义？库存调整的Reason Code用哪些？

4.关于这一个Deployment，和Template有什么不一样的地方？

关于To Be Process，大家肯定看过到很多了

只是，这里要强调一下文档的规范

使用的符号，标注的方式，页眉页脚，都要根据Template来做

不然人家也很难看懂啊

Data Conversion Approach，简称DCT，是对于Data Conversion指导性的文档

里面包括，在这一个Deployment有哪些Conversion Items。

原始数据是哪里？数据量有多大？谁提供？谁协调？谁确认？

现有的SAP数据上传模板可不可以用？

原始数据怎么转成SAP的数据模板？字段怎么对应？比如在老系统里某字段的字符长度大于SAP的字段长度，怎么解决？

......

这3个文档，是Blueprint Design阶段的关键

整理好这3个文档以后，要跟BPO review，并且sign-off

作为下一阶段Build 系统的依据

除此之外，要开发的东西的列表也要在这一阶段确定下来。

项目实施，是一环接一环的，

你收集的需求不完全或者不准，那么你的Blueprint Design肯定也不完善

你Blueprint 阶段还留下一些需求没有解决方案，如果这样开始Build系统的话，以后肯定有问题要返工

每一阶段完成的标志是BPO Confirm。Sign-off以后不能随便改。

当然不是说不能有新的需求，也有的客户不重视sign-off

但是作为PM，要坚持这样的approach，要guide用户按这样的approach来合作

制订这样的approach，是项目管理中最重要的事。

六，Build and Testing

研究技术问题是中国人的强项。

很多强人对SAP的配置很熟悉，知道能不能在SAP里能实现某个功能

但是，光了解技术，要做Consultant是不够

首先介绍一下系统环境

在SAP里，不同的Client就是不同的环境

通

常的，有一个做Config的Client，一个做Development的Client，一个Sandbox的Client（随便改随便用）还有一个

SIT的Client，一个UAT的Client，Training的Client，Mock

Conversion的Client，Production的正式Client，User Support的Client

做Config的Client不能做任何Transaction，做好配置以后能自动传到Development Client

在Development Client里做Component Test

Development Client同时也是做开发的Client

因为在Config的Client里，如果做任何Transaction，有可能有的配置改不了

比如Number Range，你做了一个transaction，号码就跳了一个了

而Development需要测试程序，所以Development Client需要测试的数据

在做配置的时候，首先，要有一个Config List

这是一个Excel 文件，包括所有SAP IMG里面所有的配置项

单独用一列来标识，哪些Config 需要在这一个Deployment里做，哪些是Cross Client的，哪些是Corss Company Code。还要记录Transport Request号码

另外，当然是Config Notes了，相信大家看到过很多

Transport是Basis控制的，这方面要跟Basis协调好

谁提request，谁approve，什么时候传

一般在大的项目里，不是你想改就改配置的

要经过GT Team Approve

Testing分Component Test，SIT和UAT

Component Test就是你做好了配置，要去测试环境里试一下配置可不可以用，这部分不需要用户参与SIT和UAT都取决于你的Blueprint Design阶段

Testing Script来源于To Be Process

跟用户确定过哪些流程，当然就要在系统里都试一下

比如创建个物料主数据，做个销售订单。。。。

SIT和UAT的Testing Script都需要跟BPO确认

SIT和UAT的Testing Script结果都需要User Sign-off

SIT和UAT的区别在于

UAT的范围大于等于SIT，有些To Be Process比较简单，很少用到，那么跟BPO确认一下，SIT测了以后，UAT就不用再测了

SIT和UAT的用户范围不一样，SIT参与的用户是Key User，UAT参与的用户是Selected End User

还有Integration Test，是指有些流程是牵涉到3个以上模块的

比如Make to Stock，Make to Order

Integration Test在SIT和UAT阶段都会存在

Testing Script，Testing Data要事先准备好，

安排测试的时候，要注意用户的时间不能冲突，有的用户参加Integration Test和某个模块的Tesing，那么时间上要分开

七，Data Conversion

Data Conversion不只是上线前把数据导进去而已，而是贯穿整个项目实施过程所要做的事

一定要有一个专门的Leader，来负责盯这部分工作。

在Capture Local Input的时候，要确定Data Gathering Scope

对于每个模块，有哪些Conversion Items，数据源是哪里？谁提供数据，谁负责收集，谁Approve，数据量估计多少

在Blueprint Design阶段，要完成3个文档

DCA（Data Conversion Approach），DMM（Data Mapping Matrix）还有DCT（Data Conversion Template）

DCA里面要详细描述每一个Conversion Item怎么样导入SAP系统中

要怎么详细呢？

比如说，用户现在的数据要清理吧，那么怎么清理呢？

采购订单没有收货的怎么处理？收完的？收了一半的？发票先收了的？发票收了一半的？

数据怎么从用户的系统导出来？手工还是有工具？工具谁准备？谁测试？

DMM是用于Mapping用户系统和SAP的字段的

不同系统中，即使同样的字段，字符长度也可能不一样，更不用说一些物料参数了

DCT是用于上传到SAP之前的模板，基本上DCT里的字段完全对应SAP里的字段了

在Build and Testing阶段，要做Conversion Tools Build & Test

这个好理解，就是开始按照之前的DCA来做事

在这一阶段，同时要展开的是Mock Conversion

通常的，Mock Conversion会有3次，Mock 1，Mock 2和FDR

为什么搞这么多次呢？

Mock

1的目标比较简单，可以只准备Go Live的30~50%的数据，生产型的企业可以准备一个完整的BOM。这样的Mock

Conversion，可以为SIT准备基本的数据，可以估计上传数据的时间，可以测试上传工具，可以保证用户了解Data Conversion全过程

Mock 2的要求就比较高一点，数据量要求Go Live的75%左右。

Mock 2的数据要为UAT做准备，需要取一个月底的时间，可以核对财务和物流的余额

FDR就是Full Dress Rehearsal，完全模拟上线的情况

上传数据的量和时间安排都要参考Cut Over的要求来做

而且FDR过程中的数据需要Sign-off，总之要模拟上线。

同时，很多这一阶段准备的数据也可以用在Cut Over的时候，比如Material Master，不用重复准备了。

Data Conversion是很重要的工作，可以通过它来熟悉用户的系统

没有经过好的Mock Conversion，怎么能保证上线能顺利进行呢？

最后，在系统上线前，那就是最终的Data Conversion。要安排好Conversion Plan

每一个Conversion Item，哪一天Upload，顺序是什么，有没有dependency

估计需要多少时间上传，数据量？谁负责上传？以及任何相关问题的跟踪。

八，Authorization

在实施项目的时候，权限是谁来实施的呢？

不是Basis，是Function Team。

Basis应该负责具体在系统中创建Role以及transport之类的工作。

但是关于决定需要哪些role，分别有什么权限，应该是Function Team的工作。因为Function Team会了解业务，知道Role应该怎么设置

权限的实施也不简单

首先，作为Global Template，已经有一套Common Role，在做Deployment的时候，就是要把这些Common Role copy as Local Role，有一些更改的作为Variant Roles

1 在做Blueprint Design的时候，要做Legal Entity Map onto Role

在这一个Deployment用到几个Company Code, Plant，哪些Common Role会用到，要列出来

2.Confirm SAP Tcode to Role Mapping

同样的，经过Blueprint Design，哪些T Code会被用到也应该知道了，要检查Commone Role里面是否都包括还有一些本地的开发会有新的T-code可能要加进去。

任何改变都需要创建Variant Role

3 Confirm Roles to User ID Mapping

这

是一个Excel文件，首先要用一个Sheet列出所有的用户信息，名字，ID，Department，E-mail之类。还有Role

Description，这个文件给用户看，当然要让用户知道每个role是做什么事，不要技术性的描述。还有SOD

Control，根据Sarbanes-Oxley所制订的审核原则，要用户知道什么role和什么role冲突。后面是重点，User ID

Mapping to Roles，这个不用多说了

这个文件应该交给Key User去完成，最后要BPO sign-off

不同的Team可能用Corss Team的权限要求，比如MM User想要财务的权限，

这就需要Authorization Leader去协调

4 接下来就是交给Basis Team去创建Roles了，技术方面的东西就不说了

5 权限测试

分2种测试，单独的Role测试和基于User ID的测试

为每一个Role创建一个ID，一个ID只有一个role，登录以后测这个Role的权限

为每一个User创建一个ID，在测试系统里，按照Function的操作测试用户的权限

6 最后，就是上线的权限准备了，

把Role传到生产系统里，在生产系统里创建ID，设置有效时间等等

这里要提到的是，权限的更改是正常的业务流程，只有要改T-code之类要transport的才是Issue

这在上线以后要特别区分开。

作为一个测试人员，如果只是将自己的责任定位在产品交付测试之后，用户使用之前，那简直就是一个灾难。如果这么思考，那你作为测试的职业规划、个人能力成长等都注定陷在一层阴影里，被项目组其他成员牵着走。

之前也有在写的文章里提到过 -- 测试人员是一定要建立主动防御体系的，这不是一个技术问题，而是几个基于技术和流程管控的工程意识。测试人员一定要能做到对风险有预知能力，有预先防范的能力，不然处在整个项目流程的最后一环，将永远摆脱不了被左右的局面。不要管业内喊什么测试左移、测试前置巴拉巴拉一堆，其实精髓就是作为测试请你尝试管理将要出现的问题和风险。

最近团队接了一个原本不该属于测试团队的任务UAT组织，注意是UAT组织不是UAT支持。关于UAT，我先强行科普一轮。

按照经验，通常UAT的组织是由项目经理和产品经理做组织的，至少我在大平安之前的几家公司是这么组织的。项目经理和产品更容易从项目进展和产品交付的角度做好把控，过程中可以请项目专家，测试经理，或专门的测试，开发等顾问对测试步骤进行补充。

当然了当前现实中，抛给了测试团队几个难题：

作为团队的测试总监，确实我开始是不想接手这件事儿的，因为在我看来确实不合常理。不管是出于行业惯例、还是人员能力等方面，我都觉得将这个事情布置给测试团队是不合理的。不过我最终还是考虑之后接手了这个事情，我的出发点是总成本：几个难题里面第一个对我们的影响最大，对方不懂如何做测试（对方甚至根本就不是有业务背景的业务or测试人员），我们每次都需要花大量的时间给不同的合作方做测试标准的讲解，做测试范围的沟通，做UAT计划的review，甚至是我们驻场给对方做UAT执行（是的你没听过，这典型的就是我是一个球员的同时还得比我去当裁判，我在禁区绊倒别人，裁判还得过来说你是不是把哨子吹一下，看算不算假摔算不算点球）。然后由于过程中项目经理又各种卡时间，导致我们支持UAT总是很吃力。所以算一下总成本，既然主要的工作目前都是我们在抗，项目经理和产品经理又做不好把控（这种做不好把控客观上讲是他们并不知道测试实施的难点在哪里，自然也无法站在测试的立场上看问题），那这件事从设计到规划到实施到进展控制都我们来做，反倒可以通过降低沟通成本而让我们的总投入下降。另外除此之外，作为测试成员尝试接入全程，提前规避验收测试风险对团队和单兵能力提升都有很大的帮助。

撇开纠结『是否行业里UAT应该己方测试人员来做组织的传统和惯例』-- 这个问题，对提升测试的全流程把控能力，个人认为还是有很大帮助的。所以，如果先不纠结责任归属，不就是组织个UAT么，有什么好怕的，撸起袖子干。

再来科普一轮什么是墨菲定律，“墨菲定律”是一种心理学效应，是由爱德华·墨菲]（Edward A. Murphy）提出的。

主要内容：

“墨菲定律”、“帕金森定理”和“彼德原理”并称为二十世纪西方文化三大发现。除了墨菲定律，其他两个也很有意思，有兴趣的可以自己百度下，对你也许也有启发。另外再说下，墨菲这个人是一个军人，是一个工程师，不是专门的心理学家，更不是什么敏捷教练。顺便这么一说，是想和各位工程师共勉下，项目怎么做，项目有什么规律，是你作为工程师最有发言权的，不一定是你的老板或者那些高价请来的敏捷教练。

If anything can go wrong,it will.（会出错的，终将会出错。） 这句话真实又刺耳的摆在我们面前，那这句话是否真的诚如字面疑似，你觉得会发生的不好的问题都一定会发生？

我先说说我的理解，还有一个心理学效应叫罗森塔尔效应。大概意思是说，暗示在本质上，是人的情感和观念，会不同程度地受到别人下意识的影响。人们会不自觉地接受自己喜欢、钦佩、信任和崇拜的人的影响和暗示。而这种暗示，正是让你梦想成真的基石之一。反过来，如果你一直心里暗示自己这个会出问题，那很大概率，这个问题终归会发生。这两个效应的总结有着异曲同工的部分，如果在项目实施中，你自信满满认为问题都可以克服，并为出现的困难做好客服的准备，那最终问题多数是会被解决的；如果你开始就暗示自己这个会有问题，基于心里暗示又忽略了对潜在风险的前置处理，那问题一定会发生。这不只是是在测试领域，任何领域不管理解成是墨菲定律还是罗森塔尔效应，都有一个潜在事实 -- 我们对自认为会发生的风险，缺乏提前预估和处理的动力，我们想当然的基于历史经验认为问题既然一定会发生，我又何必在自认为不可逆的事情前面螳臂挡车。 而这正是我们的问题所在。

那我们这次组织UAT都遇到了什么问题？下面是组织开会时，我听到的一些问题：

听完大家的吐槽，我先默默的划了一张图，如下：

画完之后问了大家一个问题，『既然大家都知道UAT有很多问题，那我们开始从什么阶段防范UAT的问题的，或者说我们从那个阶段开始做组织，开始控场的』。我指了指立项阶段，没人举手；我指了指需求阶段，没人举手；我指了指开发阶段，还是没人举手。可以比较确认的多数人还是在SIT阶段而且是SIT的后半段才开始掌控UAT的实施 -- 当然这个时候不做也不行了，因为UAT就要开始了。

这里就可以看出这个比较大的问题了，基于经验大家都知道到UAT阶段会出很多问题，但是仍旧放弃在从立项到SIT之前对UAT阶段的风险做掌控，那问题到UAT阶段你担心的问题都一定会发生。 这也就是这次UAT过程中的墨菲定律事件。 自然而然，这也可以理解为，是由一个墨菲定律带来的UAT测试危机。

当然这个问题是需要举一反三被扩展的，不局限于UAT的组织，我们在测试过程中的很多问题都是担心发生然后就必然发生了，比如担心提测延期 -- 比如需求大、架构不问题、人力不足会有延期风险，但是我们基本上不会在前期就做控制，那提测一定是延期的。所以，在我个人看来，更准确的表述是 -- 对你担心的事情，如果你不克服悲观情绪并提前做防范，那你担心的事情都一定会发生。

诚如一些文章提到的观点 -- 墨菲定律只是将生常生活中的一些现象进行归纳的心理学方面的总结。出发点是人，所以能够解决的也是人！人通过调整自己的思想，看清事情的发展方向，便不会受自己心情的影响是终导致事情不可控。 所以要先给自己定格调，测试过程中任何担心会发生的问题，都可以通过预判和防范而得以解决。

之前也提过，先撇开技术能力，你是想做一个executer，还是一个tester，还是一个QA，还是一个QC。

如果你只是按照别人给你的计划，别人给你的方案做测试实施，那你永远都只是一个executer，等着被机器和AI取代的那种

如果你能对项目有自己的分析和见解，知道如何做测试分析测试规划，那你是一个tester，但你很容易达到职业生涯的天花板。

如果你对项目测试独立的见解，对质量有良好的意识，对质量工作展开有明确计划，那你是一个QA，但你可能还不足以影响一个领域。

作为测试，请热爱这个行业，所有墨菲定律、罗森塔尔效应都只是我们给自己开脱的接口，尝试做到对全流程质量的把控能力，这才是你应该做的。

《再说说APP测试设计-1》

《再说APP测试设计-2》

《关于ad hoc test》

《干了这碗蛋炒饭 继续APP性能提升-1》

《突破测试的墨菲定律 -- 有感于一次UAT组织》

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com