记得看某个战争片的时候有个龙套（貌似还是个知识分子）跟里面说，下次在阵地上遇到敌人轰炸，就躲到以前的弹坑里好了，因为有数据显示炮弹落到同一个弹坑的概率极低，如果真落到你这个，那你也不用躲了。低到什么程度倒是没说。

这里就说到了数据，有理论依据了。

同样的工作中用某某方法你是性能高了，未来可扩展性也好了，但针对某个场景压根就不用考虑性能，人压根也不需要扩展，你费那个劲儿干嘛哦。那反过来说，现在某个功能上缝缝补补的勉强完成需求了，可能从现在时候是节约时间了，也提高“工作”的效率了，出来混迟早要还的，狗皮膏药总有无不住窟窿的时候，一旦被别人戳破，那真是自找的。这个角度到底是省时间了还是浪费了呢？

类似的问题实际上还有不少，比如修改完用户密码后是应该保持客户登录还是应该跳转强制重新登录？那现在软件质量不好，到底不好到什么程度呢？那基于现在这个Team到底有多大的产能呢？

诸如此类的问题，针对同一个项目中，可能不同工作经验的人给出的答案都不一样，很大程度上基于个体主观的感受来回答。你说改就改啊？凭啥要强制登录呢？你说我这东西不好就不好啊，微软还天天打补丁呢？有种你做的比我快。这类的声音此起彼伏。

那怎么说服各方都理解甚至认同你的想法呢？摆数据哦，针对不同的问题，设计几个大家认同的指标，各个指标都有详细的数据支持。

凡是是不是好，怀又坏到什么程度，在没有数据支撑的时候都是个体的吐槽，摆数据看5分钟，比你没事儿就觉得、认为半个小时要直观的多。当然数据只是结果，解读数据、分析数据背后的原因最后让大家达成一致才是关键。

这里只是说要达成一致，这个一致很有可能还是不对，但是至少team的理解是一致的，即使有难那也是同担啊。一个坑里刨食还互相掐架，累死！

P.S.刚刚给一哥们扎啤烧烤庆生，然后被叫去跟boss聊工作，忍不住想吐槽几句。吐槽，纯属吐槽！

If anything can go wrong, it will.

墨菲定律（英文名：Murphy’s Law），亦称莫非定律、莫非定理、或摩菲定理，是西方世界常用的俚语。墨菲定律主要内容是：事情如果有变坏的可能，不管这种可能性有多小，它总会发生。

项目实施很不顺利，小小总结+记录下想到的解决方法。

项目实施过程中总是试图说服客户将一些问题放到上线后来调整，为此会去做很多工作，虽然当时能让客户认同自己的观点，但是只要系统中有一些不愉快的插曲发生，客户随时会将前一秒的的应承推翻，黑下脸来，给我改完先。

这就是风险，根据 墨菲定律，这还是高风险呢，这时候就是考验PM的时候了。总结下这段时间的工作如果能做到以下几点应该能较好的控制这只风险怪兽。

• 1、内外部信息透明，别藏着掖着，让客户知晓现在的进度、大家的难点；
• 2、给客户的承诺一定要及时甚至超前兑现；
• 3、从业务角度跟客户沟通，试图说服客户能放到上线后调整的一定不会影响他业务；
• 4、管理好客户期望值，房子装修好了客厅是加不了水龙头的，但是要放个鱼缸还是有希望的；
• 5、及时反馈，对于客户提出来的要求快速给予反馈，反馈不等同于立即给出解决方案，及时客户知道提出问题现在处在哪个阶段；
• 6、积极主动，客户提出一个需求，发现系统中有类似其他的他可能会要求的地方，主动告知客户；
• 7、一份简明而清晰的需求汇总及完成表，客户也需要向领导汇报；
• 8、所谓信则灵，这个阶段是否能顺利推进很大程度取决于客户对PM(沟通人)的信赖，所以前面做的事情都是在给客户信心。
• 暂时就这么多想法了，实施完了再补充好。

2011-05-17 16:14:42秒，实现了Pre-Zero-Bug。那一刻我很兴奋，缓缓松了一口气，这口憋了18个月，请大家不要吝啬自己的掌声给自己一些掌声。（张继科）源代码行数：349249，表：147，视图：137，存储过程141，1 77，2 932 ，3 1565，4 164。

我这有一些关于咱们这个项目的故事、数据要跟大家分享，关于咱们这个项目的前世今生。

2009年10月Julian跟我说我们要启动这个项目，11月15日Julian领着我跟Simon来到烟台，我记得那天飞机一落地，好大的雪，当时我就心里一咯噔，一场硬仗要打啊。

来烟台后第三天，我们确定了团队的第一批队员：John、Jessica还有一个Jessica的同学，虽然Jessica不是第一批参与到项目里的哈，但是却是是第一批被确认的人选，很高兴第一批确定的队员里有坚持到现在的。建议为Jessica的坚持给她些掌声。

队伍起来了，就开始攻坚了，大家现在看到业务的输出都是我在做，实际上，这些业务的积累是Julian领着我们（John、Michael一起）做的，从流程图的编制规范，到具体的调整Julian都有参与，那真是个攻坚战，全新的业务，全新的团队，花了2个月左右，完成并提交了流程图，迈过了第一道坎，然后回北京开年会，Julian的体重目标顺利达成，因为累得，不是因为他是领导我这麽说，此处应该有掌声。

做完这个之后，我们进入了设计开发阶段，也是我们第二批队员加盟的时候了：Cherry、Yann、Arron、Lorry、AirLi。那个阶段我们很迷茫，我们面临好多的问题：不成熟的开发框架、业务如此庞杂；框架团队和开发团队分别处于北京和烟台。针对负责的业务，Simon和Julian 建议参照北森引入Scrum；Simon一边负责其他项目，一边领着Alan一起开发新的框架，针对异地问题 4月份Jack从北京过来。这道坎我们又迈过去了。×××（日期）我们给客户做了第一次Demo，客户给我的反馈是肯定的，好多地方容出错，但是我们比较喜欢这个东西。

接下来 我们迎来了第三批队员 烟台女婿 Patrick、烟台土著 Sam、青岛回来的Terry、 和测试团队 上海回来的Rebecca、Sally、北京过来的Milo。我们团队壮大了，解决疑难问题的能力，对质量的控制有了很大的提升。新的问题暴露了，流程上出问题了，设计层面很难保质保量，又请Michael和Jack开始加入设计，这道坎迈的很艰辛。

5-6月期间，我们遇到了软件行当常见的跳票，已然没希望按照既定的时间表给客户交付了，通过不停的跟客户沟通，我们将Lunch时间调整到10月份。

7月13日，我们搬家了，搬进了市长大厦，队伍也越来越壮大，SPT团队为项目开发提供了很多的后勤保障，咱们谢谢他们哈。

这是Simon也从北京过来了，各种框架问题在Simon和Patrick的支持下都能及时解决了，一波三折的Ted也加盟了，使得各种前端问题迎刃而解。我们开始使用TFS管理故事，我们开始将开发团队开始尝试分成两个小组：JJTS，JATG，我们开始尝试团队设计，让大家都参与进来。最多的时候我们可以两周Down掉近100个故事。

这个阶段，工作之外我们团队的活动也日渐丰富了，无论是迟家、大润发还是金沙滩，都见证了我们都举杯开怀身影，烟大、千里马球馆、华安宾馆都留下了我们尽情欢愉的笑声，金钩寨、幸福十六村、华信都还弥漫着我们支锅时的美食。团队间彼此也越来越了解，慢慢消除了一些工作中的不愉快，默契越来越好。

10月，Peter加盟，给团队带来很多业务的分享（Peter的小宝宝就要诞生了哦）。这个阶段我们再次经历跳票，我们开始外出取经，远赴青岛参加敏捷之旅，获取一些经验。我们加强对故事的管理，让团队来做设计，坚持使用燃尽图，大家更关注结果了。

跌跌撞撞进入了年底，大家都在准备计划 春节之旅、都在准备年货的时候，项目组在埋头苦干，为保证1月底上线，我们整整一个月，没有任何修整，直接干到大年28。遗憾的是这次我们铩羽而归，没能得到客户的认可。

铩羽回来，我们重新计划，开始引入MSF，开始调整管理团队，调整管理方法，引入设计审核确认、测试评审等等环节,稳扎稳打。终于经过１８个开发周期，我们拿到了zero-bug。

回头看看这18个月，我们团队从无到有，从小到大，大家都付出了很多的汗水、艰辛，也体验了不少的 困苦、沮丧，我们大家一直是抱成一团，一直在践行咱们的核心价值：快乐协作、目标清晰、勇于担当、行动迅速、沟通昌达、结果满意，不断坚持敏捷、不断地尝试、不断地地改进，克服一个又一个困难，迈过一个又一个的坎，一起收获着流汗的快乐，沮丧后的希翼，成长中的欢悦。

未来的日子里，我们将会面临一些已知的、未知的挑战，我相信咱们的团队能够禁得起挑战，扛得住冲击，大家有没有信心？有没有信心？

这次我们是在昆嵛山上为货运项目 登高庆生，下次我们到 会当凌绝顶、一览众山小 的 泰山上迎着日出 为拖车网庆生，好不好？

职场里，特别是初入职场最怕的学不到东西，没法往更高处走。所以各大企业开始校园巡讲的时候总是会把无条件加班之类的东西包装成，会有充足的挑战在等着你，把起步价薪水过低的情况包装成会一个良好的职业规划，而不用去计较那3-500的薪资差异。不过为啥从来没有一个企业说可以在这点上即给充足的挑战又有良好的福利能跟员工达成双赢呢。最近帮老家亲戚的小孩看工作岗位，牢骚下而已，扯远了，回到正题。

公司采用Scrum的方式来开发软件，这个过程要求所有的短平快的产出以便能跟用户交流，收集其反馈然后进入迭代改进。

由于前期人员到位不及时，各个角色人员都缺失，很多不建议重叠的角色都重叠在自己身上，整个开发的效率很大程度上取决于自己的产出效率，特别是设计这一块。设计出不来活，自己就会投入工作的60-70%的时间去做设计，这样整个项目的需求及进度反而没人管了，恶性循环其结果估计好不到哪儿去。

话说“穷则变，变则通”被逼急了没办法了，我需要更多的时间来关心需求、关心整个项目的进度，所以我做了一系列艰难的决定，这其中就有我要将设计降下去，我要抓大放小，大框架我搭好后，细节的交给开发人员自己来做设计。

决定既然是艰难的，那执行起来肯定不会顺利到哪儿去。现在还在执行中结果如何暂且还不知道。

想想这个过程其实也蛮有意思的，以前自己总觉得什么事都需要自己过一遍才感觉放心，需求、设计、甚至还会去看看大家些的sql语句，往往看到的都是过程，忽略了对结果的关注。感觉自己总是试着去当一个babyset，总以为自己会比别人做的更好，搞得自己很累，大家也不见得轻松。

倒是这个艰难的觉得让我开始轻松起来，我有更多地时间去做需求，去细化故事，没了设计的先入为主和羁绊，拆分其故事来可能会更简单呢。也能将更多的时间投入到进度跟踪，团队建设和其他的管理工作中了。

反过来看看被我决定的那帮兄弟，刚开始接手那肯定是非常非常难受的。因为以前啥都做好了照着文档干活，到现在你必须自己绞尽脑汁的不停的思考为什么要加这张表，这个字段我不加行不行，还会时不时的扎堆讨论某个设计实现是否合理，虽然在这部分上花的时间明显多了，但是开发起来却更得心应手了。我相信在这个过程中，他们肯定也掌握了一些比单纯开发更多地技能。从长期来看，无论对公司还是个人，我想这可能是某种意义上的双赢吧。

接下来我要做的就是规范设计流程，制定评估标准，以便更多的开发人员能完全的掌控驾驭在现在的框架下设计实现某些功能。当然还有更多的艰难决定去让更多地人觉得难受…

照着这个图示，利用周末时间断断续续的写，今天终于写完了，发现些长点的东西很累哦，也不知道是不是自己之前想的内容，我想还是会有很大的出入的。写个稍微长点的东西都这么累咯，想想那帮自己写书的人还真满有毅力的和乐於分享的。

相关链接如下：

写给自己看 业务架构设计

写个自己看 UI设计

写给自己看 UE设计

1.1抛弃一部分用户

我想世界上没有哪个人喜欢世间所有的东西吧，耶稣和佛祖可能能做到，所以他们死了。既然我们没办法去喜欢或者满足世间所有的人，那为什么要求世间其他的人或物都喜欢我们呢？所以别试图满足所有的用户，虽说精益求精追求完美无可厚非，但是也别在试着在一个特定的阶段去满足所有的用户啊。

就像没有天生的恶人一样，不是每个用户在系统中都只扮演一个角色，所以需要在充分了解所有用户使用感受（实在不行，来个八九不离十也够），权衡系统定位后，能抛弃的就抛弃吧，又不是《士兵突击》搞什么“不抛弃不放弃”哦。

那既然要抛弃，总不能见什么都抛弃吧，抛弃也是需要一些技巧的，这个就太复杂，回头再总结。

1.2只展示必须的数据

见过很多的内部系统，发现很多系统往往都有一个缺点就是，在页面上堆一堆的文本或者下拉框，基本上业务中药用到的所有数据都能进行录入和展示，但是整屏幕下来密密麻麻啊，完全不管用的人什么感受。

对于业务系统，特别是时效性要求高的业务系统，建议在设计初期观察一段用户的工作情况，只是把他在某个工序90%情况下必须的内容展示在他的面前，供他查询或者修改。那剩下的10%通过某种方式能从当前的工作界面调出来就OK了，没必要堆一大堆的东西放到一起，你以为你们家是QQ哦。

这里需要特别注意一点，用户评判系统好坏往往不是看，日常90%情况下系统是否能完成业务，而是剩下的那10%的情况系统是否够用，所以这个10%的设计往往比那个90%要难的多，没有别的招，还是先看看这用户平时是如何做业务的，遇到10%的情况他们怎么处理的。然后先简单的给他复制到系统里，等他们用一段时间之后再来修改这个10%的情况。

1.3让用户时刻都知道自己在做什么

这部分之不必多说，我都不晓得我在干嘛，我干嘛要用这个系统，我在用系统的时候都不晓得我进行到哪一步了，那系统又如何为我的业务服务呢？举个简单的例子，如果我点了某个扭，系统在对数据作运算，但是没给出任何的提示，你想着时候用户肯定发懵啊，到底是我点错了，还是系统坏了，抑或是我录入的数据有问题，最起码也给人来个“数据查询中，请稍等吧”。时刻让用户知道自己在做什么，系统中业务数据处在什么状态那是必须得。

这里还需要注意的是，无论用户处在哪个位置，都应该有一条可以直接退回到系统某个公用界面的方法，而且这个方法不能过于复杂，需要简介明了。在这个撤销的过程中，如果涉及到比较复杂的表单录入的时候，应该为其提供一些便捷的保存方式，以便下次能很方便的从上次离开的地方继续开始工作。

1.4为用户做推荐而不是选择

最近比较好火的3Q大战，狗咬狗一嘴毛，都TM的说为用户考虑，可是流氓行径那是不差分毫，你这帮狗日的凭啥打着为用户考虑的旗帜，私下绑架用户行为谋取某种商业利益哦。

在业务系统里（当然不是那种无人值守的系统，或者某些决策系统），特别是一些业务比较复杂的时候，给用户一些推荐的选项，是体现系统价值的最佳时期，也是为用户解决问题的最有效途径。

但是记住一点，这个推荐一定不能是替用户选择。

1.5系统内风格一直

这个话题就更简单了，看看Office系列，无论哪个单独的产品，保存总是在“文件”这个大选项卡下的（2010有大的调整），windows系列的所有产品，为什么你一上来就知道直奔开始à程序去找你新装的某个软件。

系统内风格统一，一来能有效降低用户的学习成本，从操作层面减少出错的概率；二来也能便于系统的开发实现；三来可以在某个领域形成公司产品的品牌风格。

1.6唯快不破

无论你如何设计如何考虑UI、UE，从系统角度有一点是必须坚持的。系统的运行速度不能太慢。一般人做出某个操作后，10秒内系统没有任何的反馈，就会开始感到不安；20秒内没反应，那就开始觉得系统有问题了。再多的时间之后，那就需要问候某些人的母性长辈咯。

从开发角度，能快速交付的东西，客户能及时看到，他们才会提出他们的建议，才有跟客户讨论改进的基础哦。

1.1UI的第一次取舍

做业务系统，从UI设计角度来看，第一个要面对的选择就是C/S还是B/S。

C/S模式在各种业务系统里那是老熟人了，从计算机这玩意儿诞生开始，大家就是在某个C/S的软件上干活。这玩意儿在交互使用上那是一个流畅啊，各种快捷键，各种输入方式。最大的不便就是每次更新都需要多个地方一起更新。

B/S模式那是后起之秀，虽然说“给我一个浏览器，我就能获取全世界的资讯”的说法有些夸张，但是B/S在接入上的方便那是不容置疑啊，最早的PC到现在的PPC、上网本、手机、平板电脑等只要有浏览器，就能方便的接入到对应的App。

俗话说“三十年河东、三十年河西”，C/SB/S都是各有优劣，无论选谁都需要舍弃一些东西，前段比较流行的SOA可能是一个比较好的解决方案，利用C/S的超强交互能力，借助B/S的强大展现及方便接入来完成整个系统。

不过这些都是浮云，业务系统还是要为业务服务，抓住各自业务本身的特殊性，选择C/S还是B/S抑或SOA的解决方案，都需要设计UI，只是干活的地儿不一样了。

1.2参考行业标准、遵守行业准则

所谓“先入为主”，既有的印象那是很难打破的，所以在应用系统上能有一些行业内成功案例的参考，是一个很值得庆幸的事儿。

但是参考不等同于抄袭，不妨留意下Baidu、Google、各大电子商务，他们在对信息的展示上那无非就是那个套路，列表+详细。为什么呢？我也不知道，不过稍微揣测下觉得也不难发现，我们最早的时候去图书馆看书、去查字典，都是先找到一些关键字（如首字母等）之类的信息，然后再去翻看详细信息。那我又猜最早的互联网上由于带宽等资源的限制，大家只能先看到个精简的说明，然后再去找自己喜想要的详细内容；或者由于信息太多，造成了某种程度的信息过载，所以某人发明了一种类似图书馆看书的方式来展现信息。

回过头来说应用系统，最常见的应用系统应该是ATM了吧，你看无论新冒出来多少家银行，都没人去修改那个该死的输入密码的键盘。为啥，一来技术不够成熟，二来大家习惯了。

对就是习惯！其实所谓的行业标准，就是某种长期坚持下来的习惯，当然不排除一些为了约束某些行为的规范。习惯那是一种太TM难打破的壁垒了，参考行业参考标准，准守习惯那是相当必须得。

1.3为用户价值服务

先来说说什么是用户价值，用户通过系统能完成他要做的事情，那系统就提供了用户价值。

软件或者系统首先要做的事情是为用户提供价值，为用户价值服务，那UI 更毫无疑问必须要为用户价值服务了，先让他能正常干活，无论使用起来是爽的不行，还是憋屈的骂娘。

还是那个ATM，其实每次我去取钱的时候我最烦的就是输入密码，为啥不能搞过指纹或者其他的我用起来简单点的设备来确认这个卡是我的呢？虽然我不爽，但我也只是不爽而已，因为我已经可以通过这玩意儿取到银子了。

我去工行的网上银行上查看我的账户明细，每次都强迫我看到那个该死的选择时间段的页面，然后才能去看到我要看的数据，我也很不爽，可还是我最终还是看到了我要的信息。

1.4兼顾商业价值

这部分比较无奈了，因为任何业务系统最后都是需要用来换银子的，只有给公司换回来银子后，才能有银子进到个人的户头。

换银子的事儿就会有很多的讲究了。

一般业务系统那是先签合同后开工，也就是说完成某个活是有DeadLine的，那你总不能在UI上花个两三年吧，先来个哪怕操作起来稍微复杂点的但是不耽误人家实现业务的东西吧，他们用起来顶多也就骂骂娘，不至于没得用，连这个骂娘的机会都没有哦。

现在不是都流行甚马精简版、旗舰版之类的功能分级吗？你总不能把旗舰版的UI让精简版的用吧，至少这两个版本在某些功能里的有差异吧。

再来看看Gmail，界面那是相当简介，操作也是极为顺畅，但是边边角角里还是特意流出来了一堆地方放广告哦。

1.5尽量少的UI交互

在一些应用系统里面，最常见的功能无非就是填表了，在设计这些个表格的时候，自己发现了一些可以参考的原则。

界面一定要简介，任何一个框或者下拉框，只要有可能尽量给人一个默认值。在安排好必须的要素后(记得显著提示)，把那些非必需的输入或者选择扔到某个该死的角落里或者干脆别出来。

”好奇害死猫”，好奇心人皆有之哦，对于任何一个界面的某个钮、输入框，你放上去，用的人肯定会下意识或者无意思的想一下，我按下这个该死的钮或者在这个狗日的框里天上字儿后会怎么样呢，会不会出错，不点不填会怎么样呢。

1.6减少锦上添花的功能

这个道理跟上面一样，多了个东西在界面上，总会让人多想一会儿的。为什么会有这条呢，是自己最近老犯这个错，为了show技术而作设计，真TM的害死人哦。举个例子，别为了展示Ajax而作一个自动完成之类的功能。不能为了设计而设计，设计是为了某个目标服务的，脱离这个特定的目标，狗屁不是。

顺带说说大家日常用的某些软件，狗日的就是强奸用户感受哦，一对乱七八糟的功能，我一个都不想要。

1 业务架构设计

由于这个项目于公司和我个人都是全新的，而且公司的骨子里含着咨询的基因，所以在项目过程中免不了要给客户调整、优化工作流程。也就有了我想要说的业务架构的设计。

这里要说的业务架构不是一个大而化之的业务，而是指的需要在系统中实现的业务部分以及系统将如何配合其他非系统中实现的环节来为客户提供价值。

1.1合理切分业务模块

说到这个系统内外环节的衔接，就不得不提业务模块的切分。业务模块的切分对于一个具有一定规模的企业而言，往往是一个无法言语的病痛。

如果各个部门之间如果完全没有业务上前后关系还好说，但我想哪个企业都很难切的那么清晰吧。举个例子谁家都有个财务部吧，财务不直面业务数据，但是老总往往又比较关注银子，保不齐会要求财务的来点统计报表吧。企业打算上系统，当然的希望系统把这部分工作完成了，就出来了传说中的中国式的报表。这本来还不算什么，可是财务在不是那么了解业务的前提下，会把这个报表的数据源头压到业务部门去，这么一来二去，离杯具也就不远了。

这个时候需要的是对业务的整合，梳理客户的业务，划分业务模块，将原来穿插在各个职能部门的业务按照实际的业务流向（汇报线往往是一个不错的选择）从新组织，也就是常说的柔性组织，理出来这个组织之后才能开始就各个业务模块来做细的流程梳理。

1.2清晰而简洁的业务流程

实际上无论是在业务模块的划分还是业务流程的梳理，作为系统开发商往往都很被动，无法大刀阔斧的去调整既有的东西，到了梳理某个业务模块的业务流程的时候，客户可能又会把系统当成万能的（特别是用管了Excel的人），往往一个很细枝末节的东西都希望能在系统中完成。

例如在审核审批过程中对一些说明等的字段的吹毛求疵，不是说这种需求无法被满足，而是应该将更多的精力放在整个系统业务流程上，为什么需要这个审核，审核关联的那些数据的前后关系是怎么样的，如果只是一个过一眼的知情权，那给你一个打印的功能而减少流程节点，加快业务流转是不是就可以了。

我的另外一个观点就是，别把用户当ze，这个字眼不好听，但实际上在跟客户理一些业务的时候往往他们会不直接的把别人当ze，要求系统封的死死的，搞得整个系统拧巴的很。如果不是一些特别敏感的数据，放开了又能如何呢，只要不损害企业的利益，没必要加的那么死死的（当然不是说完全不做控制），等你着实需要这么控制的是咱再来Update咯。

自己在这个还未上线的系统里做业务设计的时候，也定了几条原则，实际效果如何还需要上线后来检验，但是至少在跟客户讨论的时候还蛮有作用的。

1.3设计内聚的业务总线

内聚的业务总线还是跟上面提到的具体到各个业务流程，尽量减少业务流程之间的穿插交织，对于实在掰不开的业务，直接做两套业务层面的控制。

1.4设计统一的业务接口

就像OO设计或者OO开发里面一样，引入接口（好像接口就是来之日常的真实生活）来屏蔽差异。在某些业务流程的入口处设置一些行为统一的业务接口环节。僵化业务入口，将所有的变化控制在入口处，降低后面的复杂度。

1.5尽可能多的依赖基础模块

这个自不必多少，源自于内聚的业务总线，内聚的东西势必要求减少外部依赖，那无法杜绝依赖的时候就依赖公共的基础模块，MS的Excel一定要运行在Win下一样，所有的用户信息都要从组织架构里取。

写完才发现，这部分的内容太多说教，缺乏实际的案例与具体可操作的方案，先这样吧，经验的缺失实在是难以避免。

最开始，客户主管会计说她需要需要一个财务轧帐功能，需要按月查看应收应付、实收实付、预收预付情况。我们就按照各需求给客户做了轧帐功能。

做完之后给客户现场演示，他们也认同了这个功能，觉得是他们想要的功能。演示完后的第二天这客户的主管会计电话过来沟通。说需要按照不同的业务类型来做轧帐。当时我正在做一些其他功能的设计，只是简单的记录下她的要求。

今天她再次电话联系我，说给我发了个邮件有一个她期望的界面。我当时心想真是个好客户，都直接把UI 给我设计好了。后来一看还真是有那么几分样子，Excel里列举出了他们所有要求。

后来一细看原来他们的要求是前后矛盾的，就预收预付这一块，一开始客户是要求按照她什么时候录入系统来做完实际业务预收预付的时间。可当她自己开始解释自己设计的Excel表的时候发现原来她们还需要一个转凭证的功能，并且按照凭证时间来做轧帐。

这个过程本身很有意思，也让我开始慢慢开始尝到Scrum的甜头。我很庆幸我没有马上去动手设计某些具体的UI或者DB，没有一开始的就埋头很细节的东西，而是等到另外的时间来做一个讨论，而且这个讨论时客户发起的。

觉得这个事儿跟某些大家常说的“生气时不做决定、高兴时不做承诺”很像，不在兴头上胡乱做决策。因为这时候往往会不自觉地屏蔽掉很多的其他信息朝一个死胡同去走。