分享第一弹：狸先生

讲道理，这个项目二次启动的时候，我的内心其实是拒绝的。客栈商务同学告诉了一个让我想哭的消息：“客户回来了！项目重新启动。”我的第一反应是：“WTF？？？跟我开玩笑的吧？！”

不是开玩笑。这个项目的大致时间线是这样的：

>2017年5月18日项目启动。

>磕磕绊绊到6月底后端开发快完成的时候客户消失。

>尝试联系客户到7月底，无果。

>9月初的时候，付款日的前一天，客户神奇的出现了，携带“巨款”(我猜的)，要求重启项目，继续开发。

> 9月项目启动。

>2018年1月中旬，项目上线。

客户消失的时候的处理

当客户失联的时候，客栈和我集体懵逼，因为之前没遇到过这样的客户，大家不知道怎么处理。在联系了几周后，开发者几乎要拿我祭天了（我也很绝望啊），项目也不能永久挂起吧！于是我提议，如果还是联系不上客户，我们(客栈、项目经理、开发者)签订三方签收协议，并将协议通知到客户那里，不管客户有没有反应，协议等一个月，如果一个月后还联系不上，就付款给开发者，项目结束。

项目二次启动时候注意事项

1、跟客户重新确定需求范围

由于二次启动的时候，项目已经搁置了太长时间，我几乎把需求都忘了。并且客户还是带着大量的需求变更回来的。所以我的第一反应是梳理需求，确定需求变更范围。好在客户的需求变更大多集中的管理后台，用户端只调整了几个页面。于是我就协调后端工程师排查，看对已完成的后端的影响有多大，同时去联系了之前对接的前端工程师。巧合的是前端工程师手上项目正好马上结束，于是就跟他讲了这个项目的情况。明确告知他这个客户可能后面会变更需求，后期可能需要他得高度配合。前端工程师表示愿意接这个坑，哦不，是项目。

2、让客户明确变更范围、确认报价

3、由于客户有“逃逸”的前科，我很怕后面托管费用又各种拖，甚至消失。这次启动的时候让客栈商务同学明确跟客户约定，一次性托管所有剩余的项目费用。客户表示同意。这里得感谢客栈商务同学的鼎力支持！

项目启动后开发问题：

第一阶段的时候，后端这边已经把api开发完了。二次启动以后，后端一边要应对前端工程师的调试，一边又要继续管理后台的开发，进度比预期的要慢不少。这应该是前面核对需求的时候，未考虑到管理后台变更对接口部分的影响。

需求变更问题，与第一阶段的明显不同，就是客户提出的需求变更比较频繁、琐碎。现在想来，导致这个问题的原因是客户提供的原型不完整，而我们在项目重新启动的时候，也没有进行类似于像1980这样的细致梳理。在客户提出需求变更的时候，我的第一反应往往是：OK，没问题，我们先来评估下工作量，然后报个价吧！一来二去，客户提出的变更就明显变少。然后针对已经提出的需求变更，私下评估了下，大概是1-2天的工作量，跟开发沟通以后，开发也愿意处理，于是就没有追着客户补报价，而是在大群里协调开发人员支持，免费帮客户处理这些问题，这个阶段给客户带来不少对开发人员的好感度，后面测试阶段的不顺利的时候，客户对开发的宽容度也很高。

到测试后期的时候，客户还在提出一个新的需求，这个时候我基本上只假装“隐身”，哈哈：只要开发人员比较配合，也愿意帮着客户处理，我就睁一只眼闭一只眼。但是后遗症是，新的需求会带来更多的影响，可能联动着其他功能做更多的修改。后面发现后端开发的质量越来越低，于是我赶紧出来终止了这种开发模式。一方面我这边在群里提醒开发要反复自测、一方面，我这边私下跟客户解释了这种模式的危害：这个阶段(测试、修复bug)不建议提任何变更性的需求，哪怕是很微小的变动，因为我们不确定这些变动会不会影响到其他功能的代码，如有影响，可能是联动性的，这样我们的项目可能永远也结束不了。客户最终接纳了我的建议，不再提新的需求，只在原来的基础上进行测试、修改、返测。

测试阶段问题

在项目快要结束的时候，客户跟我抱怨了一句，感觉项目的测试没起到什么作用，都是他自己在测试、返测。在测试一开始参与进来的时候，测试用例和测试的任务是没有分开的，我提前建立了测试的子项目，结果测试进来后一看开发还没完事儿，于是测试用例拖了很久才开始写。写的测试用例也差强人意，不过当时我关注开发进度比较多一些，测试这块没有管控到位，就为后面留了隐患。

开发完成以后，测试提出想有一个缺陷管理工具来管理缺陷。我知道客栈上得gitinn的订单管理是可以用的，于是推荐他使用这个。但是从后面的情况来看，这个东西有些不足，一个是测试提出问题以后，指派人不方便，里面只能看到ID，看不到账号(现在好像可以了)，另一个问题是，上面的问题描述不清楚，跟踪并不方便。

我每天登录上去只能看到有多少问题没处理，而无法统计属于谁的任务有多少。一开始测试描述问题很不清晰，并且有歧义。于是我在群里面提示她细化描述，最好配上截图。然后后面她再提交的问题，描述就略好一些。

在测试提出的问题未处理完的时候，我曾经尝试让客户提前介入用户测试。但是由于接口有种种问题，流程无法进行下去，客户参与积极性不高。

测试提出的问题处理完以后，用户开始测试。但是一开始测试，就会提一些调整性的需求，而一改需求，就会联动出其他的问题，有时候还会导致流程无法进行。然后流程走通以后客户又提出添加一个文件导入功能。这个时候我基本是放任的状态了，因为从客户的立场上来说，提的问题的确必要，但是站在开发者角度来说，这又属于新的需求。开发者没提出异议的情况下，我也不想挑起开发者的情绪，这个客户明显是预算不足的，如果因为这点需求导致开发者跟客户僵持，那结果肯定不会好。

在这样的背景下，项目的测试工程师基本上处于“消失”的状态，问题的提出和返测基本都是客户在亲力亲为，客户才有了上面说的抱怨。所以在项目结束的时候，我在想，测试工程师的工作范围到底该如何界定呢？是测试完成交付用户UAT测试的时候就结束了呢，还是一旦用户UAT测试未通过，测试人员还是要重新设计测试用例进行返测？我觉得测试的工作应该是贯穿原型设计结束至用户签收的整个阶段。

测试并不简单。遇到一个专业的、敬业的、态度好点测试简直需要造化。客栈有必要对项目的测试进行更细致的职责划分(很高兴看到目前已经拆分了测试用例和测试两个阶段)、明确更规范的输出要求、提高更大的成本比重。在这之前，还是需要项目经理个人来把控测试节奏。

项目最终顺利上线了，但是就我本人而言，我对这个项目的最终成果并不是很满意，有一些地方其实还可以做得更好的。如果后面还会有新的需求，我觉得还是可以做一下的，哈哈。

编者按：感谢狸先生的吐槽和分享，为大家提供一个优秀的，规范的测试是非常必要的目标，会和大家一起逐步建设起来，同时gitinn工具的实用性也是我们今年工作的重点哦，敬请期待！

狸先生个人博客，欢迎围观：