快速开发后的思考
一个月前我们启动了一个看起来像是“闪电计划”的项目，用两周的时间完成系统的改版，内容包括原型设计、界面设计、开发、测试、上线。时间紧任务重，看起来有点像不可完成的任务。最终通过整个团队的密切配合，和包括周末在内的加班加点按时完成了任务。但仅仅是完成，并未出彩。这是我第一次和整个团队一起参与较为完整的一次项目开发，从上线前到上线后，整个过程中似乎总是不那么平坦，有许多细节值得思考。但是时间紧急来不及追究，现在有必要静下来回顾思考，有哪些好的地方是可以继续沿用的，有哪些差的地方是需要改进的。
我们现在的团队和小的创业团队没什么差别：
- 成员之间没有一起开发过完整的项目，缺少磨合
- 我们的工作流程、沟通方式、开发流程没有严格规范，大部分是通过即时沟通来达成意见一致，说好听了是敏捷，说难听了就是原始。
- 需求的修改、代码的联调没有明确的流程，没有形成规范的文档，以后想要翻看之前的记录将比较困难
- 为了追求快速完成项目，牺牲了代码设计架构的时间。没有良好的架构，以后需求改动或扩展会比较费力
这些特征决定了我们必然会以现在的流程来进行开发，但由此产生的问题我们有没有方法来改善呢？答案肯定是有的，现在需要回顾一下整个流程，慢慢来寻找答案。
在确定需求的时候，我们全部的人员开了一次会，5个小时左右，把所有要做的东西过了一遍，有疑惑的地方当场拍板应该怎么做。应该说是解决了所有的疑惑，因为我们明白这样的会议不会再来一次的，接下来就要进行开发了。我觉得做的比较好的是，我们在讨论过后总会得出一个结论，这一块该怎么做，那一块改怎么做。可以说我们的会是“有结果的”，这相当重要。如果仅仅是停留在发现问题、提出问题的层面，那这个会也就和没开一样了。这是值得沿用的一点。
但是我们的会就没有缺陷吗？显然不是。我们这次改版涉及到的功能点太多，因为是改版而不是重新做一个东西，所以有很多是我们没看到的。所谓没看到的就是一些隐藏的业务逻辑，需要在特定的场景下才会发生。我们的旧系统逻辑比较复杂，我们的人员从产品到开发都是新的，对老系统缺乏整体全面的了解。我们整理出了新的需求，但有一个致命的缺陷：我们没有全面的考虑新的需求与旧的逻辑有哪些冲突，我们没有考虑旧逻辑之所以那样做的原因，功能点之间存在的关联或是前置条件，这些都没有清楚的了解。
这个致命的缺陷直接导致我们在开发的过程中不断发现有遗漏的地方，以至于不得不先完善遗漏的东西，最终的开发量粗略估计有需求文档上面的1.5倍。
其实过来人都有这样的经历，甚至觉得这是喜闻乐见的，项目开发大都如此嘛，没有不会变的需求。但这样的情况并非是什么好事，那我们该如何改善呢？我们开了5个小时的需求讨论会，难道还不够吗？当然不够，因为我们只开了一次。因为我们是在改版，是在重构，在开发的过程中必然会发现第一次讨论没考虑到的东西，在积累了一定的问题后，我们是不是需要重新拿起需求文档，重新审视一遍，再来一次简短的讨论会，该添哪些东西，或者是时间不够了该砍哪些东西。
我们的开发流程还是比较顺利的，因为明白时间有限，所以采取了简单处理、重复迭代、快速成形的方案，有一些新的设计想法都没有采用，而是沿用了原来的较为稳妥的做法。比如我们计划想减少请求数，把一些页面内容做成异步获取的，但最终考虑到改动的东西会比较多，就放弃了，还是复制粘贴了不少代码，每个页面还像原来那样单独请求。页面加载速度没有提升，但保证了稳妥不出问题。再谈优雅什么的，那更是没有了。
我们每天早晨开一个15分钟左右碰头会，通报一下昨天的进度，核对一下今天的任务。让每个人都心里有数，这一点还是做的不错的。
现在需要反问一句了，开发的过程中有什么问题吗？有。因为我们还是发生过返工的。除去需求变化的原因，由于考虑欠缺，没有明确方案就急于写代码，导致写了一大半的时候发现方案有误，最终更改方案重新开发，这一点还是很伤的。现在需要告诉自己一句了：就算时间再紧急，也要想清楚了再动手。事实上，有明确且正确的方案后，编码是占用不了多少时间的，这一点一直会给人造成误区，认为做项目主要就是写代码。
开发完后就是紧张的测试了。我们没有专门的测试组，创业团队的风格嘛。于是从别的组拉来两个实习生，外加产品经理、开发人员、客服妹子，组成了一支测试队伍。利用周六周日的两天时间，完成了产品的测试。测试的方式是最原始的功能测试，说白了就是以用户的身份，在页面上点来点去，把各个功能块都跑一遍，看看哪里走不通了。我们也没有bug库之类的辅助工具，测试人员测完一轮就群发邮件通知一下，或者直接通过IM来交流，然后开发根据邮件和讨论组中的bug来修改。
这样的测试流程很明显是有问题的。对比一下，如果我们建立bug库，我们规范了的流程大概是这个样子：测试人员提交bug到库=>开发经理/组长分配bug给组员=>开发修改bug=>开发提交给测试返测=>测试人员标记bug通过/bug仍存在再次提交到库。
上面的流程看似冗杂，但少了其中任一环都不能保证一个bug能被最终解决，并且让大家知道这个bug已经处理了。这个是很重要的，大家能对每一个问题都有一个清晰的掌控，否则当用户来我们我们的时候，我们的回答只能含糊不清，因为我们自己都不清楚这个问题到底是解决了还是没有。就从我们实际情况来看，我们也确实遇到了以下问题：
- 对照邮件来处理bug很容易会有遗漏，因为没法标记这个bug是已处理还是未处理，或者是测试有误不处理。全凭人脑记忆。在讨论组里提bug则更容易遗漏，因为可能开发人员压根就没看到这条信息。
- bug的认领问题。有些bug需要前端来改，有些需要后端来改，没有一个人来统一分配，分工不明确。组员自己认领自己的bug，或者相互沟通协调，时间成本都太大
- 开发修改完bug后，没有给测试回复邮件来说明bug的处理情况。bug最终的处理结果只有开发清楚，没有一份可以保持的文档来记录，测试并没有百分百的返测他所提的bug，只是提完就算结束了。这样缺乏互动沟通，大家最终对结果的了解都是含糊的。
这样看来我们的测试流程确实是有很多问题的，这也直接导致了我们的产品上线后，不断接到用户反馈，其中大多数都是bug。那我们当初为什么要这么做呢？答案只有一个字：快。在有限的时间内，一个创业团队，根本无法建立起来这么完善的测试流程，这也是客观事实。看来这问题是无解了，真的吗？或许这个时候我们需要回归到问题的根本上，思考这样一个问题：花一定的时间建立一个完善的工作流程，最终下来是会浪费时间，还是节省时间？我们想答案并不是那么绝对的。
通过原始的沟通方式，使用原始的工作流程，我们终于把产品折腾上线了。产品上线后的稳定期持续了两周之久，不断有用户反馈发现了bug，客服那边都忙坏了。开发这头也是手忙脚乱，我们建立了一个讨论组，大家都在里面反馈发现的问题，bug像炸弹一样向开发狂轰滥炸，场面可想而知。
在这个阶段，我们陷入了像测试阶段一样的困境。太乱了。这个时候发现的问题都是零零散散的，甚至都没有邮件来汇总，所以都在讨论组里面提。开发人员一变修改代码，一边留意讨论组里又提了什么问题。有时候一个bug修改的时间长，讨论组了已经攒了n个bug，有时候大家发言太多就把一些问题遗漏了。而且这个时候都是靠人脑在记忆，很容易就忘记了到底有多少bug存在，这个时候就会出现有人在讨论组反映了一个问题，却没人回应的状况。与此同时，由于遗漏了反馈来的问题，客服、运营又会感觉这边响应不及时，无法向用户交代。总而言之，就是一个字：乱。
问题在哪里其实是显而易见的，我们缺少一个人来统筹工作，应该是项目经理的角色。但是像这样的创业团队，无论是产品还是开发，每个人都会奋斗在第一线，没有一个人能抽出身来统筹一下项目，或者说把所有反馈的问题整理一下，做成一个列表来挨个对过。如果我们没办法专门有一个人来统筹进度，那么就必须抽一个人出来做这件事了，我想最合适的还是产品经理，同时担当QA的角色。这个时候对产品经理的要求就比较高了，必须快速的与开发进行有效沟通，所谓有效沟通就是一定要得出一个结论来，这个问题该如何改，现在就动手。由产品经理来驱动整个过程。
有时候会感慨，项目节奏太快，都没有时间思考了。其实这是一件可怕的事情，像这样“闪电计划”似的项目开发，是非常宝贵的经历，如果不能从中学习到一些东西，真的是太可惜了。现在有时间静下来进行思考了，我们的不足暴漏的很明显，在今后的工作中必须针对性的进行调整，只有这样才有提升的可能，否则永远只是重复劳动的机器。
好久没有码字了，感觉整个行文都有点生硬了，最近看了阮一峰老师写的为什么要坚持写博客，非常赞同里面的观点，因为写作能促使你不断的思考，而思考对于人的提升至关重要。
