从失败的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可能觉得我们目前的功能还没有那么复杂。所以自测应该没问题吧。在没有测试人员的情况下，为了保证软件质量，覆盖率高的单元测试就很有必要了。

希望我们以后能够做的更好，加油！