Archive For 八月, 2010
起这个题目是源于一个以前看过的美剧 Fringe ，讲述的是基于时空重叠理论下两个宇宙，一些对公众而言很前沿、很新奇、离奇的案件。正好我们的项目是全新的队员，用的是全新的框架，全新的控件，连我这个PM也是全新的。 团队初建，一人多角再正常不过了哦，因为推不出去。 客户需求最熟悉的人肯定是最适合来做设计的。这时候没法管你是不是新手，该上路你就的上！上就上吧，到了路上再说咯。恕不知，这路不是乡间小道，而是高速。 熟读唐诗三百首，不会作诗也会吟啊。新手上路了，不会漂移还不会1档啊。现下就碰到一些由这个新手引发的这样一些问题。 就一块1024*768的地儿，该怎么折腾你看着办。没啥好折，先搬以前的东西往上套吧，套出来好不好看，先一边凉快去，把活干完再说，什么！1024*768塞不下了，不够地儿？贴膏药上tab。一个声音出来了，tab太复杂了，简化 。没辙，好吧，再来个1024*768….这么一分,人客户不干了，我没事要跑几个1024*768哦，改吧。那还是贴狗皮膏药吧，给你个tab，切换吧。 搞过几次1024*768这块地儿后，这个新手就开始喜欢上贴狗皮膏药了，贴来贴去，开发的不干了。 开发：“你以为狗皮膏药真像你画的这么容易贴啊，你这么贴我搞不出来哦。” 新手：“兄弟我就要结果，怎么搞你看着办吧！” 开发：“$#@!$#$(&(&),框架组，这个控件不好使，我都调试一天了，出不来设计要的效果啊” 框架：”稍等，我看看先！” …. 时间就这么过去了2个月。 来了个棘手的活，这丫的要留下每笔操作业务，DB层面设计没招了，新手问了问谷姐，找到了一些设计，发现还蛮不错的链表式的DB设计，在数据库里存着一颗树，也试着演练了一遍，发现这些招数不是那么难，然后就找来一干人等讨论这个招数难用程度，是否能满足业务，讨论后通过！。新手毕竟是新手没能很好的预估这个是个七伤拳啊，好设计伤了自己哦。大家为了这颗树累的半死。 几次折腾下来，team开始焦虑了，因为复炸的设计，让大家无法按进度进行。新手开始要调整了。但是发现上的这条高速是那种不跑到终点没出口的高速，甚至连叉路口都看不到。怎么办呢，蒙头走到黑吧。
因为是个业务系统，首要的一定是客户能完成日常的业务。做IT的多少都有点完美主义的情节，总希望把东西做的尽善尽美，雕琢自己的每一件作品，加上用敏捷这种灵活的开发方式，需求是源源不断的冒，甚至还包括了对客户工作流程的调整。业务中大家比较慎重的就是钱的问题，所以我们还做了很大一部分的财务辅助功能。 业务系统中大家都以为会有明确的分工，但实际上只有Title不同，实际上一个人从头到尾把业务跟完很正常，再正常不过了。这时候就无法将某些特定的操作固化到某个Page上了，因为谁都要做全部的事儿。 还是因为业务系统，用户天天用这个，要求要简洁，操作方便，速度快。可客户的业务调整的相当频繁，客户的客户朝令夕改那是再平常不过了，客户是希望在一个不动的地儿就把活儿干完（这个未经验证，个人理解如此），这种频繁改动给设计带来很大困扰。