在最近的一段时间，工作上经常会扮演团队管理者的角色。随着新人慢慢适应了新环境，接下来要让他们真正成长的重任落到了我的肩上，当然，这也是我成长的过程，也是团队成长的过程。
上个星期接到了一个任务，我们开发的一个最大的系统在经过了上线的考验后，又来了一批共8个的需求更新。我想了想，决定让新人来做这次更新：如果让熟手做可以很快做完，但是新人又会少一次成长的机会；新人一上手就这样大的项目更新是有风险的，于是为了控制风险：新人写代码，熟手来看他们更新的代码并负责测试。这样在有效控制风险的同时，新人也得到了锻炼。
还是以案例来说，以下几个案例很有趣值得人思考：
1. 不注重用户行为的一致性（consistency）
有一个需求是需要用户在不完成一个item之前不能在items之间切换，用户如果切换，便弹出窗口提示。于是新人J做完了，我看代码并测试。发现行为不一致：用户有三处地方可以切换items，但是这三处地方的行为细节不一致，有两处是先弹窗后跳转到没有完成的页面，而有一个地方是先跳转到没有完成的页面再弹窗。我给他演示了一遍他写的代码效果，他没有发现有什么不同。
点评：用户的一致性在产品中非常重要，同样的规则用户不希望在这个按钮上是这样的处理效果，在另外一个页面的那个按钮上另外的处理效果，这样用户会感觉到迷惑（confuse），以及不习惯，这是有损用户体验的。
解决方案技巧：尽量跟已经上线的功能特性相同。比如已经上线的处理是弹窗，那么现在也弹窗。
2. 只看自己要更新的需求描述。
新人H被分配更新第五个需求点，于是他猛看第五个需求点并马上改完了。不过同时提出一个业务逻辑上的冲突（conflict）要我跟客户第二天确认， 我当时答应下来。不过回到家后想了想，发现第八个需求点把我们的担心给解决了。于是第二天把新人H和新人J叫在一起（新人J负责第八点需求），让新人H给新人J讲讲昨天他提出的业务逻辑的冲突，于是新人H讲了，不过马上新人J就提出了质疑的观点，因为第八点需求让冲突消失。
点评：其实每次的更新需求文档是个整体，在看分配给自己的任务同时，要过一遍所有的需求点，做到心中有数。因为客户的水平还没有到把所有需求都分类好地发给我们，所以需求需求之间也许是有关联和制约的。
解决方案技巧：开发人员除了自己的任务外，可以大致扫描下整个的需求更新范围；管理人员应该在开始就把所有的任务分配到个人，而不是按天今天分一点明天分一点，这样管理人员可以初期把相关的更新分给一个人，如此便可以避免这样的情况发生。
3. 不抓住本质核心
有一处更新，因为涉及到的逻辑比较多，所以如果想不到核心点上去就得花很多功夫。我一开始便想到了这个点，但是我故意没有说，而是让新人们去想该怎么办。于是三个人先用英语在办公室，然后用中文在会议室，花了两个小时的时间，提出了7种技术解决方案，一种比一种复杂，改动更多，而且最后能不能实现以及会不会带来二次bug（regression bug）都不知道，差点都想求助客户了。我提出了我的观点，站在业务逻辑上，只用简单的代码就搞定了需求。
点评：在改bug之前，一定要对业务逻辑一块熟悉，至少对那一块的业务逻辑熟悉。不要一上手就马上想用什么样的技术解决，往往最简单的东西是最厉害的。仔细理清思路，抓住最本质最关键的点然后解决掉，比在表面上想来想去好得多。
解决方案技巧：如果对业务不熟悉或者思路很乱，通过用笔在纸上画图或者到会议室用白板画图是个有效的理清思路的办法。找到核心点往往用简单的技术逻辑便可以解决，不用搬重型＊＊了。
其实在修复bug的时候，特别是针对这样的特大系统，思考力变得重要，开发人员不要仅局限于某一块任务，也不要上手就开始写代码，多思考可以让人尽快抓住bug核心，从而用最少的代码解决最正确的问题。
在这整个作业流程当中，特别是第三个案例，在我们会议室交流了两个小时的时间里面，发现了大量的沟通问题：往往两个人对话，听别人讲的那个人往往看似听到了，其实什么也没听。在沟通中不会听是致命的，这些沟通方面的问题＊露，大大坚定了我下一步抓沟通的决心。
