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