Fork me on GitHub

从失败的Release中吸取教训

一次失败的Release

去年8月份加入一家创业公司,和原同事做VR相关的产品开发,到18年正月初七,总共release过两次,真正经理了一次从0到1的过程。第一次release产品初步成型,大概在10月份,在公司内部做了一次宣发,我们做的是ToC的产品,但这次release没有真正意义上的C端客户,倒是可以拿着这个雏形产品到处去找内容提供商;另外可以拿到市场上去"试点"了,找一些潜在的目标用户,去收集反馈;再有就是需要向投资人交答卷。

第二次release就是直接面向实在的客户了,release时间点在正月初七。我认定这次Release是失败的,是因为软件质量出现了问题——产品拿到使用现场的时候发现诸多bug,系统根本跑不通,在现场调试了三天才将就着能用。想想自己曾经信誓旦旦的说这次发布的目标是要保证软件健壮性,出错率保证在5%以内,脸不禁红到了脖子跟,呵呵。

这篇文章只从项目管理和软件开发的角度来阐述这次release之前的诸多流程,用以分析项目失败的原因。

一个好的软件产品,软件质量是基石,软件质量指的是软件的稳定性和流畅度,软件质量过不了关,软件再怎么易用,业务功能再牛逼,也称不上合格的产品。

研发团队成员

研发团队总共四个开发,我和原同事做后台和VR终端开发,一个新员工做网页前端开发,一个员工做Unity开发。做美工的就不算了。没有测试,没有项目经理(敏捷教练)。我和原同事是资历比较深的,另外两个员工经验相对要浅。研发团队是原同事和老大组建的,不知道为什么忽略掉这两种成员角色。或许是因为支出吧。

为什么会失败

这次失败,当然有客观原因,譬如成员角色就是不完整的,譬如时间紧迫,但这些都不说,主要还是从自身找找原因,这样在下次遇到相同情况的时候,我们不能保证做到完美,但至少能保证减少错误或者没有大的错误,臻于完美。

因为团队成员角色的缺失,所以我们自己要担任起这些角色的功能,其实这都是后话,我们没有意识到它的重要性。

先从自身问题说起,我以前的背景全部是在发展相当成熟的大公司里任职开发工作,估计原同事也是类似,没有小公司创业经验,缺乏大局观。原先经历的项目都号称是敏捷开发,眼睛看见了项目经理如何运作一个项目:如何进度跟踪,如何协调资源,如何应对产品团队提出的需求变化等等;看到了测试人员如何工作:写测试计划,写自动化测试用例,和开发人员沟通测试结果等等。但这次经历说明了,眼见为『虚』,这些其它角色都没有亲身经历,过脑没过心。从心里知道这些程序是必要的,但没有见过缺失这些角色会造成什么后果,心里自然而然的还是将自己定位成开发人员,按照开发的路子一直走。 没有项目管理整个团队就是一盘散沙,没有目标,没有计划,没有需求优先级,产品过来需求就去做,做到什么时候没有预估,最后,失败是注定的。下面详细说说我们这次项目运作过程中缺失的流程:

没有时间节点

这是致命的,老大把release时间确定了,研发团队应该将研发测试的时间节点也定下来,什么时候代码写完,什么时候单元测试完,要留出来多长时间的系统联调时间,什么时候code freeze.时间确定下来后,各个阶段的目标就明确了,写代码阶段要保证代码质量,自测阶段要尽可能的发现新加代码中的问题,联调阶段至少要保证没有大的bug,小bug要尽量清理掉。code freeze出release版,坐等上线。

我们这次只有一个release时间,其余的都是瞬息自然,最后可想而知,运送设备当天勉强把软件装到设备里,没有测试完,发现的问题没有解决完。

没有进度跟踪


敏捷开发标准流程中的一环就是standup meeting,由项目经理了解每天项目进度,这其实是把写代码的时间节点分成了小目标,每个开发人员把需求的完成当做自己的一个目标,一个小目标又可以分成几个小小目标,例如,一个模块的完成就是完成了一个小小目标。项目跟踪可以让项目经理了解大致的开发进度,和大的时间节点相关联,如果过程中遇到问题,可以提前做出判断,采取补救措施。项目成员也可以通过这种方式让目标更加明确,遇到问题及时做出调整,并且也能了解其它项目成员的进度。

很可惜的是我们也没有standup meeting,目标变得模糊起来,这会导致问题,就像上学的期末考虑,把所有问题最终都堆积到临考试的前两周,结果可想而知,能及格就不错了。

需求传递流程不规范

先说问题,我们的产品经理传递需求都是通过口头来传达的,有以下几个缺点:

  • 口头传达会有信息损失,表达出来的东西和想法可能就会有出入,再传递到另外一个人的脑子里,理解的可能和你表达的又不一样,一次次传递,到最后的实施人员,最终可能面目全非。可能有点夸张,我们的团队也很小,沟通成本也小,但终究还是有问题。你碰到过开发和产品打架么?开发:你就是这么说的,我做的完全是照你说的做的。产品:我没这么说过,你肯定是误解我的意思了。呵呵。
  • 人的想法是会变的,人是会遗忘的。今天以为东西这么做好,头脑里有一套完整的功能流程,但明天可能觉得那里不对,但却想不起来具体是哪里不对了。
  • 有些东西不是一下就能理解的,实施人员得到需求后,可能一下就以为自己明白了,但设计和实现过程中才会发现产品需求有更深层次的用意。在反复揣摩产品需求,加深自己的理解时,记在脑子中的需求可能没有原先那么清晰明确了,好吧,又得去找产品团队确认。

我说这么多的目的只有一个:需求需要书面形式的写下来。产品团队写的过程中会多一个反复揣摩的过程,怎么表达更准确无误,自己的这种想法对不对?然后写下来,写下来就是写下来了,产品可以在这个基础上反复更改,直到无误。实施人员可以反复的理解产品的需求,这回反复理解的需求每次都是清晰可见的。

我们这次也碰到了需求理解不到位的问题,开发人员的功能实现和需求传递者的想法出现了偏差。

最后说说测试的问题

最近研发团队加入了Scrum Master新成员,有比较丰富的管理经验,但他做出的决定是先不要招测试人员。功能自己做自己测试。我对测试人员的看法如下:

  • 我觉得开发和测试是对立的,某种意义上来说,开发人员测试自己的代码往往不客观,尤其是单元测试覆盖不到的功能点,开发往往认为自己的功能是没问题的,有一个比喻:程序员写出的代码就是自己的孩子,哪有老给自己孩子揭短的。呵呵。因此这两个角色看问题的角度是不一样的。所以我认为测试人员还是必要的。

Scrum Master可能觉得我们目前的功能还没有那么复杂。所以自测应该没问题吧。在没有测试人员的情况下,为了保证软件质量,覆盖率高的单元测试就很有必要了。

希望我们以后能够做的更好,加油!

posted @ 2018-04-15 21:00  HarlanC  阅读(...)  评论(... 编辑 收藏