下午前台组派来的人报到了，是个穿着西装、留着板寸的帅哥，手边还经常端着一杯咖啡小口呷着。这扮相在IT行业还真有点特立独行，所以大家都叫他“发哥”。
紧接着两个刚刚毕业的新员工也报到了。他们在入职培训中表现突出，被S总看中后直接截留到了小M的小组。两人中一个来自南方，身体结实，不像IT男倒是像个武师，大家都叫他“南拳”；另一个是北方人，高高的个子，长长的腿，大家都叫他“北腿”。
大师兄、发哥、南拳和北腿，小M转眼之间成了4个人的领导！
相互熟悉了一下之后，小组一起讨论了工作计划和分工。商量后决定小M带南拳负责第1、第2项需求，主攻界面组件和屏幕事件控制程序；大师兄带北腿和发哥负责第3～7项需求，主攻报文处理和各种打印程序。
会后小M马上跟前台组长打电话约时间确认功能。电话刚打通，还没等小M说完前台组长就痛痛快快地说：“你现在就过来吧，我在会议室呢。”小M满心欢喜，没想到前台组长对自己的工作这么支持。
到了会议室，小M发现除了前台组长，还有后台组长和几个技术骨干。上个会好像刚刚结束，桌子上堆着一大摞文档，白板上画得乱七八糟，明显是激烈地讨论过什么问题。后台组长一边收拾东西，一边神秘地对小M挤了挤眼睛说：“好的，后面就看你的了！”
小M刚坐下，前台组长马上介绍，刚刚前后台两组之间争论了半天，终于确定了功能部署的原则，现在正好该跟小M讨论这个问题。“功能部署？”看着小M一脸困惑样子，前台组长耐心地跟小M解释起来：
“需求规格只会明确需要实现什么功能，至于功能放在前台还是后台实现并无要求。但是，同样功能放在不同的地方实现效果不同。例如，如果把账号和户名的一致性校验功能放在前台，用户输错了账号后系统会立刻报错，用户纠正后才能继续输入；如果将校验功能放在后台，用户需要输入全部信息提交之后，才会接到后台返回的错误提示。从客户体验上看，校验功能放在前台合理；但是，从系统部署和后期维护角度看，校验功能放在后台更简单方便。因此，功能部署必须综合考虑用户体验、系统开销和运行维护等多种因素才能确定最终原则……”
小M正纳闷前台组长为什么这么细心地跟自己说这些呢，突然发现前台组长正“不怀好意”地盯着自己笑，心里立刻涌出一种不祥的预感。果然，前台组长突然拍拍小M的肩膀、充满信赖地说：“刚刚跟后台组确定，大部分校验功能放在前台实现。但我觉得你们组用工具实现才最合适！你们肯定行！这样我们前台组的工作就轻松多喽！”
听到这话小M气就不打一处来！光想着前台组轻松了，怎么不想想我们组又要增加工作量呢！看着前台组长那一脸坏笑、顿时一股热血涌上脑门，恨不得冲他大吼一声“没门”。可小M无意间扫了一眼会议室，发现大家都屏着气看着自己呢。突然想到与S总约定：“领导要有领导样，什么时候都不能发牢骚”，于是强忍怒火没说话，转而默默地盯着前台组长端详起来。
说实话，对这位前端组长小M总觉得捉摸不透：公司有人说他很“狡猾”，经常连蒙带唬地达到目的；可从他派发哥加入自己小组的这件事上，又觉得他很大气；不过，这会儿刚刚有的一点好感又荡然无存了！
小M仔细品味他那半真半假的微笑，觉得他这是在“将”自己呢！如果自己发火，就是承认不行呗；如果忍耐着接下来，他正求之不得！想到这里小M觉得不能意气用事，应该认真地沟通才行，于是问道：“你能先把功能清单给我看看吗？”
前台组长本以为小M又会像以前那样暴跳如雷，发现小M居然没有生气倒是有点意外，于是换了一副相对真实的笑脸，拿起笔记本电脑走到小M旁边，把电脑屏幕往小M方向一转：“喏，这就是校验需求的功能清单……”
不看不知道，一看吓一跳！小M发现这个清单不仅内容多，中间有好多名词都不知道是什么意思。这可怎么办？想来想去只好来个缓兵之计：“要不你把文件发给我，让我回去商量一下。”前台组长没反对，但是马上追问：“什么时候能给我个答复啊？”小M硬着头皮说：“明天中午吧！”
拿着功能清单小M一路小跑地回到小组，赶紧跟大家商量该怎么办。大师兄和发哥是有实际经验的“老人”，两人看了一遍之后对小M说：“这活儿咱大部分可以接啊！”
听到这话小M心里安稳多了，但嘴上还是着急地问：“怎么个接法儿啊？”看到小M一副焦急的样子，发哥故意拖着长声卖起关子来：“出具体方案的话晚上要加班了，这个……这个……”小M自然明白啥意思，马上说：“老规矩，夜宵我请，地方你定！”大师兄和发哥笑了起来：“这还差不多！”(www.xing528.com)
五个人对着功能清单认真研究起来。遇到不明白的名词，知道的人就解释给不知道的听；遇到搞不清楚的问题，大师兄和发哥就打电话请教各自的朋友。还是人多力量大，渐渐地大家思路就明确了。原来，功能清单的内容虽多，但是整理之后基本上可以归为几类，而每一类的处理方式基本一致：
●有效性校验。简单的如日期，格式为YYYY-MM-DD，月份、日期必须在有效范围；复杂一些的如手机号码，格式预置为000-0000-0000，当输入13612345678自动显示136-1234-5678，这样容易判别是否为有效号码。
●规则校验。通过明确的业务规则校验数据合法性。比如某种账号的长度18位，前17位是序列号，第18位是校验位；系统可以按照约定规则根据前17位计算出第18位应该是多少，再与第18位实际值进行比对。如果一致就是正确的，如果不一致就说明有输错的地方。
●双敲校验。通过验证两次输入值是否一致来确保数据输入的正确性。例如设置初始密码的时候，要求两次输入一样才认为设置成功。
●双人校验：通过验证两个人对于同一字段的输入值是否一致来确保数据输入的正确性。例如，对于某个关键字段，可以在第一人录入之后将凭证转交给第二个人再录入一遍，如果两个人两次输入一致则认为数据有效。
●授权控制：对某些字段设置一定条件，满足条件之后必须请高级主管授权后才能继续进行。例如，交易金额大于某个限定条件时，则主管屏幕上弹出授权请求，主管输入正确密码后才能进行。
……
分类整理之后大家马上一起商量技术方案。讨论后发现，如果校验的流程标准、且只涉及一个字段就容易用快速开发工具实现；因为只要标识出对一个字段需要进行哪种校验，就可以在进入或离开这个字段时通过触发一个程序进行控制。大概测算了一下，这类相对标准的校验功能占了清单中总需求的85%以上，看来前台组长希望小M他们完成校验功能的想法不无道理。对于剩余的15%的需求，因为涉及两个及两个以上字段的组合逻辑，快速开发工具无法确定字段之间的关联，所以实现难度较大，还是前台组自己实现比较合理。
小M把这些结论记录下来并整理成文档，大家一起把方案仔细看了一遍，又进行了一些修改，然后兴高采烈地吃大排档去了。小M怕有疏漏，吃完夜宵之后又把方案看了一遍，这才放心地睡觉了。
第二天中午12点，小M准时找到了前台组长。前台组长说“怎么样？都能实现吧！”小M没有正面回答，而是说：“我们逐条过了一遍需求，整理了一个方案，要不您先看看方案？”前台组长扫了一眼小M的文件，有点调侃地说：“怎么搞得这么复杂啊？”但是在后来小M介绍方案的整个过程中，他却一直非常认真地听着没有打断。
介绍完方案之后，前台组长重点询问了剩余15%不能实现的功能的原因，又提了一些具体的技术问题，然后就开始讨论双方的接口标准和实现方式。半个多小时之后，前台组长伸了个懒腰，一脸轻松地说：“行了，就这样吧！一起吃饭去！一会儿食堂就没啥好菜了。”听到这话小M有点被闪着了，对比昨天他那咄咄逼人的架势，今天问题解决得也太轻松了。小M不敢相信又追问了一次：“就这么定了？”前台组长说：“是啊，你们想得比我仔细多了！”
听到这话小M明白为什么很多人说前台组长“狡猾”。昨天，他不断施加压力是为了把小M逼到绝处，这样小M和他的团队才会重视此事并认真准备！今天，当他看到方案的详细程度就知道这肯定是深思熟虑的结果，他的目的达到了！
“真是老奸巨猾”小M心里笑骂道，回想起来也有点后怕，如果昨天不是及时控制住了情绪可能早已贸然跟他顶撞起来；更可怕的是，自己连问题都没弄清楚，争吵起来不仅不可能有结果，还会伤害大家的感情！
现在，小M对自己在这次“事件”中的应对措施很满意。确实，面对抛过来的问题，先别急着防卫，不妨先后退一步，分析清楚之后再去应对。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
