首页
学习
活动
专区
工具
TVP
发布

分享第一弹:狸先生

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

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

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

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

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

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

> 9月项目启动。

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

客户消失的时候的处理

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

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

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

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

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

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

项目启动后开发问题

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

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

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

测试阶段问题

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

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

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

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

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

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

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

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

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

狸先生个人博客,欢迎围观:

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180207G0EN4100?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券