天外孤鹰

对于自己研发自己维护的团队来说，研发的成本不是到测试完毕上线时就截止计算，恰恰有可能恶梦在这时才刚刚开始。

说到研发的成本，最近加深了一下印象。

按照我的体会，对于既研发又运维的我们来说，研发的成本不光只是项目考察、设计、编码、测试，很大的部分还在更长期的运营维护。设计和编码时多花一些时间，可以减少后期很多维护的成本，这其间包括运行期维护、错误处理、代码更新等。有过一两年，我的手机会隔三差五的在夜里响起，要么是报警的短信，更多的是报警的电话。以至于我现在对手机铃声非常敏感，一定要弄成渐强的那种，接电话时必然会急促地说：“喂？什么事？”，哪怕是三更半夜，特别是对某个负责系统维护的 jj，当真是美梦也成恶梦啊……

看上去，对互联网公司而言，时间非常宝贵，能早一天上线，可能就意味着成功。听上去很正常，但也不尽然，gmail 的突然崛起就是个很好的例子。真的很突然吗？面世之前不知道怀胎几年呢。催生出来的早产儿多半会营养不良而夭折，至少也是体弱多病。

其实还是小学时就懂得的道理，要打好基础。就像金字塔，底部非常宽阔，当然，对研发而言不太需要考虑把石头运到顶部的工作量（当然随着项目代码量的增大，学习成本也随之增大）。如果按照体积计算（实际上考虑每层的高度都相同，问题缩减为面积计算）的话，越靠近底部的层耗费的时间越多，所以时间/产出的曲线是条抛物线。在最初，可能在相当长的一段时间内看到的都只是地上画好的线，和几块石头。实际研发的过程中当然不允许这么干，但在项目的早期越是急于求成，基础就越不稳。

基础不稳定的后果当然不会是崩塌，首先是竞争不允许我们出现这样的失误，其次一般也不会坏到那种程度。但这将会导致建筑工人（研发人员）忙于东补西补。有时候甚至是上面还在垒，或者在修改些东西，下面要求支撑，工人就那么几个，只好疲于上下奔跑。这样的情况是我的真实经历，上下奔走就是在两种不同的工作之间切换脑袋里的思考场景。当然长期这样也起到了健身的效果，我习惯于把整个结构记在脑子里，而不是纹在身上。也造成了我对于不顾全局只为完成任务而做的代码的痛恨。

总的来说，我更倾向与多花一些时间在搭建系统上，而不是忙于找补。找补不是创造，相反会影响士气，但节省出来的时间可以用于创造。

手头做的一个项目，同时也是个完全从头开始的产品，最近终于快要结项了。能这么说，是因为绝大部分功能已经齐备，再有一两个星期完善打磨，就可以交付测试了。开发的过程中比较注重边写边测试，所以希望测试的同学们能找到一些我不知道的 bug 出来。

回头看看，从底层到页面，包括部分页面设计，一个人开发，还是花费了大约半年的时间（具体开始时间有待查证），其间走了很多弯路，设计改了很多次，特别是 javascript 部分。这当然得感谢领导对我的容忍，因为除了例行演示之外，我应该是最不主动汇报工作的，而且很多该找同事协助的，我也因为兴趣的原因自己做了。

这么多次改动，和我凡事喜欢自己解决有很大关系，比如页面设计的部分，第一次做有界面的程序，感觉做设计的 mm 比较难说服（是个借口吧，出于对面对面交流和冲突的回避），于是很多事情就自己动手了。另外，感觉像 c++ 写的程序，稍大一些，通常是仔细设计避免改动的，javascript 程序改动起来容易多了，且是第一次开发，所以想到更好的设计的时候，总会有种改掉现有的冲动。

在一个综合性互联网公司做一个产品，做这样一个产品，不知道会和那些专门做同类产品的网站有多大区别，但我很羡慕另外一家通常是综合性互联网公司做的同类产品，总是在不断更新。这应该不是项目型产品的产物，而是产品型的项目。二者区别在于，前者的产品在项目（通常从开始到结项时间较短）结束后就很少继续发展了，而后者则是只要产品存在，项目就不断在跟进。

越是通用的东西，越不容易过期。比如我们使用的 smtp, pop3, http, ftp 这些网络协议，虽然普通网民很少会知道（我指的是不光知道名字），但他们已经是网络侏罗纪动物了，目前还在爬得欢。所以越是底层，越是通用的项目，其生存期越长，需要不断维护。这时所说的底层并不仅仅指界面之下的那些，还包括用以构成界面的架构和基础性代码。

我觉得在一个致力于长期发展的互联网公司里，特别是成功的公司，需要有这种长期性项目。这些项目（Project）的负责人（maintainer），需要是相对稳定的人，充分深刻的理解项目，以维持项目的方向性（不能充满拍脑袋出来的点子）；维护这些项目则作为项目负责人的日常工作之一，决定做什么不做什么，决定怎么做（主要是架构和设计方面），同时，决策的权力决定了项目负责人要有代码审核和最后的质量保证的责任，这非常重要。项目负责人的选定，水平很重要，大概占 60% 40%，还有 40% 60% 应该是责任心和自愿，否则很难长久，强扭的瓜不甜……

回头看看遇到的项目，可以有两种方式实施，一种是向一个长期项目提交需求，然后项目负责人决定怎么响应；另一种是人和项目之间没有长期关系，有需求要做，就临时安排人手进行。前者的结果应该是枝干分明的参天大树，负责人易人时交接也很清晰；后者的结果应该是像蟹爪槐，就算没有分枝，也会有骨节，有转折，甚至有连接，长期进行下去，需求越来越难实现了，虽然盘根错节看上去真的很艺术。但前者比较理想化，因为很难确定一个人会在一个公司呆多久，特别是互联网公司人员变动非常频繁，但长期价值大，潜力大；后者则很现实，特别是越是界面的东西，越容易是生存期短，变化快，可能很快就没有价值了。

特别羡慕那些开发网络游戏的团队，会长期以整个团队为单位迁徙，做一个游戏平台或引擎会有相对长期的开发时间，特别的，是他们允许有一个相对长的蛰伏期，但蛰伏期过后，加不同的界面就能快速推出新的产品。这也像现代汽车的开发，越来越像共用底盘的方向发展，这样降低了设计成本，制造成本（生产线等）。但对我们而言，能实现吗？

其实如果没有人员离开的风险的话，开发人员的时间可以按照 80/20 分配，80% 的时间做突击开发的项目，20% 的时间进行项目维护。当然，对于项目负责人而言，这 20% 的时间是做决策，做设计，分派任务，然后视改动多少，由项目其他参与人员花费 80% 或 20% 的时间实施。这其实是我在很长一段时间内思考的一个问题，怎么在部门内部仿照 sourceforge 的项目组织。

这个产品，这个项目，日后将会是如何呢？或许做这样一个理性极强的工作有些不应该，但我个人对写出来的代码是有感情的。写完了的代码就不再管了，就像让自己的孩子去流浪，养不教，父之过……

看到一篇讲 UI 设计的文章说他的手机地址簿不好用，原因是每次都要去找联系人，而不是把最近联系的人放在最上面，就像输入法对待经常输入的词语那样。他的手机刚好和我相同。

刚看到的时候觉得说的有道理，因为输入法也确实就是这么干的。但在今天早上拿起手机的时候，发现并不是那么回事儿，这其实和个人习惯有关。我习惯了每天早上到了公司会给家里发条短信报告一下说“我到了”。每天如此，所以无论联系人，还是手机的输入法，按键的顺序，以及为了适应机器的慢速度，需要在两次案件之间间隔多久，都已经成了习惯了。也就是说，我可以不用看手机屏幕，或者只是在最后发送的时刻才扫一眼确认一下。如果这手机的联系人或者输入法中词汇的顺序经常变化，那操作的速度会减慢很多。

其次想到电脑的输入法。我用的拼音输入法，词的位置并不怎么变化，我可以很快的输入完拼音按一下数字键，有时候连翻页页都记住了。还要翻页，看上去挺慢。但如果把翻页和数字那几个键也当成是输入一个字的按键序列的一部分，那么这输入法唯一的问题就是按键次数了。你可以记得很牢，靠手指的灵活提高打字速度，而不是每次都去找你经常输入但却被输入法给改变位置的词。

这样我就得到一个暂时性的结论：要想提高速度（某种程度上说，就是方便性），得把眼睛从操作中解放出来。

所以我一直不喜欢鼠标，这东西是个不精确的输入设备，即使仔细看，在一个比较繁杂的桌面上也有可能找不到他在哪儿。所以鼠标有一个功能，就是可以设置按下某个键的时候，在那附近出现个对焦的圈。而我习惯的键盘操作就不同，在网络传输慢（有时候是机器处理慢）的时候，我可以不按屏幕连续输入我要干的事情，然后可以离开一下，等着它干完。

好像是得到了一个没什么价值的结论，现在鼠标的应用比键盘广泛多了。但是换一个角度想，从用户使用习惯的角度想。无论输入法，还是地址簿，不管是否会按照使用频率调整位置，总有人会感到不满意。可以让应用去适应用户的习惯，也就是说，用户“培养”他使用的产品的习惯，而不是“遵循”产品的设定，而且这种培养应该是建立在不额外花费用户的时间的前提上的。比如用户输入了一个字，字母和最后的数字之间停顿时间很短，那么这家伙可能就是我，不用费心给我调整词频；如果一个用户习惯输入完拼音以后按上下键，那么给他调整词频会让他觉得舒服；如果一个用户只按字母键，他可能是个不懂中文的老外，哈哈。

总会有办法的。

虽然是从 UI 开始，但已经远远超出 UI 的范畴了。

试用了一下 adobe acrobat 8 的自动滚动功能，键盘控制比较出我意料，但确实很方便。

既然英文里把这功能叫做 scrolling，于是想到长卷。可以把阅读的过程看作是拿着一个放大镜沿着一幅长卷“上下求索”（用 window 这样的词可能不如放大镜直观，但我觉得更合适），上下键控制放大镜的运动速度。在自动卷动状态下，上键会减缓向下卷动，按一次速度就慢一些。并且，在速度降到很低的时候，再按，卷动方向变反，开始向上卷。下键的功能相反。

这个功能和 google picasa 的滚动条功能有些类似，picasa 的滚动条改变的不是视窗位置，而是视窗上下移动的的速度。

没有哪一样更好或更差，其实这两个产品的这种设计很符合产品的定位。picasa 是个图片浏览器，内容是一幅一幅独立的图片，使用滚动条时通常是在寻找想要找到的图片，这时鼠标操作比较多，所以采用滚动条的设计很自然（特点是要按住鼠标才会滚动，松开的话，滚动条恢复原位，滚动停止）；acrobat 是个 pdf 阅读器，人们使用 auto scrolling 时，大部分时间是在顺序阅读，键盘操作可以解放人的手，专注于阅读。

另外，emacs 和 vim 在向后翻页的时候会保留上一页的最后三行在顶部（vim 需要专门设置一下，行数可以更改），这样的功能对我而言也比较有用，特别是在阅读一些长句子时可以帮助我保持阅读连贯性；而且，在 auto scrolling 模式下，如果不这样做，那页顶部的那一行有可能会马上被卷上去而看不到了，这是我在使用 acrobat 是确实遇到了的。

现在 ajax 流行，网站的操作界面越来越 application 化，考虑如何设计操作如何完成时，需要更多地考虑产品功能。

P.S. 我怎么觉得以前好像写文字记录过这功能……又觉得当时也写过这样的 P.S. ……

据说 google 的设计理念里有一点就是“让用户快速的离开”，简单的说就是让用户快点儿找到自己想要找的东西然后走人，并不在 google 本身做太多停留。这句话也被很多人引用。

我觉得比这更重要的是让用户下次还来。很快离开确实很重要，但是离开了以后再也不来了，也就没什么意义了。换句话说，要成为用户达到目标的最快的途径。这样才会有“回头率”。旅游景区的商店什么的才会坑一算一个，不考虑回头率吧，因为一次就把好多次的钱都赚出来了，呵呵
(continue reading…)

产品设计是骨架，是灵魂；技术实现是血肉。

如果没有好的产品设计，就会血肉模糊一片，混沌如肉球一般不知所以；如果没有好的技术实现，就会变成只有灵魂附着的骨骼……好像都比较恐怖。

技术实现兮，产品设计之所倚，产品设计兮，技术实现之所依。

总的来说，我觉得产品设计占首位，从技术的角度，可以加一些花。产品设计人员决定了市场定位，以及功能取舍，界面设计等，再有俩好的技术实现，那就是一个健康的有血有肉有灵魂有骨架的生物。有些技术能够实现的东西，可能在最初设计未必被考虑进去，但加入进去后，会让整个东西作出来更加强壮，或者更加漂亮，或者……总之，健康完整是首要的，但也不能因此拒绝这生物看上去太基础（？）太简约（？）太……

总归是写程序出身，考虑产品设计时，对于一些功能的取舍的原则是“不伤害整体设计”，而不是一定要对整体有利（这个有利是指，有可能一些功能是特别小众的，用的人非常少，但顺手加上至少不会有什么破坏）。

BTW: 我发现二值逻辑其实挺害人的，在 0 和 1 之间有那么多的灰色地带，对这部分的取舍才是最重要的。