Michael Chen's Blog

感同身受

2012-05-11T00:00:00-07:00

自从开始做产品之后，我就成为了产品运营人员的一部分。每天，我与行政收到同样多的邮件。出差请求，感谢，抱怨，我都一一看在眼里，记在心里。得益于之前出了无数的差，因此对于出差人员的感受非常直接，然而在行政这边，估计许多人如我一般，对她/他们了解甚少。与程序猿不同，她们（多数是女性）的时间被扯得稀烂，最新来的事情优先级最高。她们善良体贴，乐于帮助他人，一点点的工作失误自己会难过得不行，而来自同事的称赞则能让她们高兴好久。

这种真实的体验让我对产品与用户之间的距离有了更深刻的理解。产品还在试运营。一天行政苦笑着跑来找我：网页出错了，500 Error。我立刻几乎可以想象，她正在使用着软件，点着界面，突然之间这个恐怖的、白色的、带着几行红色粗体的错误信息页面出现在面前，对于一个没有任何编程经验的用户，是多么恐怖的体验。一种无法解释的内疚油然而生，我看着她说：对不起，理解你的感受，我马上修复。

她楞了一下，迅速说：没事，不着急。

几分钟之后修复好了。她在IM上回复说：太感谢了！

这些让我对软件的价值重新考虑。我们需要真正的使用这些软件，才能够得出真正的体验，并能够在使用不便、出现问题时真正感同身受的说：说：对不起，我理解你的痛苦。我们正在修复。

很多软件忽视这个过程。软件的设计者、制造者、销售者、客服与用户之间，通过各种部门、KPI隔离开来，然而又妄图通过各种制度来标准化服务流程。可惜，销售者不用自己的软件，客服也没用过自己的软件，制造者根本见不到用户使用的样子，又如何能够真正体会用户的感受，制造出贴心的软件，提供贴心的服务呢？

2000行代码

2012-05-01T00:00:00-07:00

早在写《架构腐化之谜》的时候，我就意识到，造成架构腐化的根本原因是系统复杂度变大的必然趋势以及人类遗忘的天性。延缓项目腐化最好的方法，是根本不给腐化的机会。生活中，自然通风、阳光透亮、家具摆放合理的、不留死角的房间出现虫子的可能性很低；代码也一样，一份简单、符合直觉的代码，放在复杂度完全可控的代码库中，能够极大的降低学习的门槛以及避免腐化的可能。

包括自己在内，很多人当然以为这只是美好的想法。绝大多数开发者仅仅能尝到项目早期的甜头，在后期则进入了愈发沉重的深渊。对于文中所说的似乎只是一个遥不可及的想法。为了证明这个是否真的可行，从去年10月开始，我在自己的产品中进行了一个尝试：在保持功能正常增长的前提下，项目总体功能代码不超过2000行。

现在是什么情况呢？从去年10月到现在，git统计数据如下

414 files changed, 42824 insertions(+), 698 deletions(-)
430次总共提交
Code LOC: 1568     Test LOC: 799     Code to Test Ratio: 1:0.5

功能代码总共不超过1600行代码（当然未包含大量的CoffeeScript以及HTML/Sass代码），完成了大部分的核心业务逻辑。未来可见的功能也应该能够在400多行的空间里完成。系统中也存在不少能够提取为独立Gem的地方，可以继续进行隔离简化。

应该说得益于Ruby简洁的语法，以及在rubygems社区提供的各种高质量的gem，让以前不可想象的麻烦变得几行代码就能搞定。

我们得到了什么好处？今天新加入了一名程序员，花了点时间介绍产品背景之后，在不到2个小时的时间里，就完成了一个典型的功能。并且还顺带修正了一些代码上的Bug。

Rails固然是特例。但推广到其他的语言，只要遵循以下原则，应该是毫无问题的：

Don't Repeat Yourself - 绝对不要重新发明轮子。github上fork数量多的项目基本上已经相当成熟了。即便有问题，fork, fix, pull request的响应时间比以往任何一种方式都要迅速，还能回馈社区。
遵循约定，遵循约定。在某个时候总忍不住自己写了类似于get 'cities/edit'在routes.rb中，但随着类似的代码越加越多，最终索性就变成了resources :cities. Rails是经过许多工程实践的框架，其中的最佳实践很多时候是经过验证的。对于其他技术框架也应该一样。有时候发现了异常情况，不要为这种异常情况特殊处理，约定化也许是更好的方案。
隔离，隔离。凡是与核心业务无关的功能代码，在找不到开源替代的时候，想办法将其通用化。比如我们用到了解析openflights的机场数据。这部分与核心业务毫无关系，将其隔离为Gem，再引用，能够减少无关代码干扰，形成知识分界，对于专注了解系统有莫大好处。
警惕未经使用的功能、代码、注释、甚至数据库字段。保持代码库总在最精简的状态下。

这个产品已经上线。在可见的未来，2000行的界限还是够用的。等到超过的那一天，我再写写看看。也许那一天可能永远都不会到来。

与真实数据一起工作

2012-04-26T00:00:00-07:00

大约几个星期前，同事找我帮忙看看一个关于类似于TODO/Action的手机UI如何设计。看到他们的正在工作的界面之后，我完全没有感觉：在TODO List界面上，零星的放着abc, def, dfsg之类的随意字符；顺着链接点进去，里面放着的是完全无法建立情感联系的blabla文字。我完全无法想象如何在这种场景下进行UI设计——软件本身只是生硬冰冷的工具，用户贡献的数据才是血肉之源。数据被粗心的对待时，作为开发人员你与用户之间基本失去联系。这种状况下我们如何能最起码保证设计是贴心的？

之前在自己开发的个人项目中也有不少需要用到人名的情况。当然不会采用类似于ABC之类的随意字符，但仍然采用了类似于张三丰、任盈盈之类的名字。发布之前用户都笑了：这是什么啊。把名字换成类似于李键、赵文斌（如有雷同纯属巧合）之类的名字之后，用户开始更为慎重的对待这个系统。

设计师在这方面做得很好。他们会很耐心的抽象出一些典型的用户（Personare），取个典型名字，放到真实的业务场景中，所用的词汇和数据看起来几乎跟真的一样。而程序员则在这方面疏于修炼——大多数仍然满足于仅仅将功能完成。一些更为惫赖的公司则索性把开发阶段的产品截图放到自己的产品介绍中，随处充斥着客户姓名是张三、一张机票100.00元、留下了一段内容是abcd123的留言等等截图。用户在看到这样的粗糙的车间半成品的时候，他们如何能够想象这个软件能够与自己真正的业务过程集成呢？

软件是给人使用的。从软件构建到软件递交到用户手中的时间应当越短越好。真实数据——作为最直觉、用户应该最关心的部分，却经常被开发人员忽视，而这部分是开发人员最直观了解用户如何使用系统的途径。如果你无法想象真实的数据，很大程度上意味着你根本不了解你的用户。

PS. 在准备给学生的作业中，我专门查找了国家农产品的价格数据库，以及最近的购物小票，以期给学生更为真实的开发体验。构建计算机思维与自然界的联系，构造更有用的软件，从身边的数据开始，应该是最简单的切入点吧。

忘掉过程

2012-04-24T00:00:00-07:00

透明度似乎成为越来越重要的一个目标，特别是在做咨询相关工作的时候。目标？计划？阶段交付产物？是不是保持持续的沟通？

在我从事咨询的过程中，这些问题一直困扰着我。在从事离岸开发的过程中，也存在各种的报表、邮件、日常的交流。会议和谈话占据超过实际工作的30%的时间似乎是一件很正常的事情。

这并非有什么不好。持续的反馈永远都是重要的。有时候客户买的，并非仅仅是最终的交付产物，在交付过程中的一言一行，能够给客户莫名的信心。想想小时候你花着几毛钱等着大叔给你做糖人，那糊糖人的过程与最终拿到糖人的喜悦，很难分得清哪个更重要一些。

很多公司很看重过程。“没有功劳、也有苦劳”便是其中的典型。即便最终结果不好，过程中尽力了，也算是可以理解的。然而当产物可能产生更大的影响范围的时候，这条规则便行不通了。

一个粗劣的软件——比如那个火车票网站，很可能是从业者起早摸黑做出来的，那有怎么样呢，它给几十亿人带来了痛苦；一个最终看起来很山寨的网站，你仍然可以呕心沥血的说，经过长时间的抉择，采取了这种方案，但用脚投票的用户根本不会买账。相比较而言，对最终受众的有针对性帮助，真正做出兼具艺术美感与人文关怀的产品，人们自然会从产品中体会到设计者的良苦用心（甚至不可言传）并自发的成为拥护者。

这条规则放在办公室运营的时候，如果过于注重过程，则会产生无数雷声大没雨点的动作。比如，今年目标是5000万，那么我今天招了多少人，明天内部做了多少培训，后天等等等，把这些动作敲锣打鼓的发扬光大，固然显得动作不小，最终即便失败，似乎也显得说得过去了。

当受影响的受众超过一定规模的时候，忘掉对过程的过度宣传吧。只有受众真正接受产品之后，他们才会对产品的制造过程产生兴趣，否则只能沦为另外一个毫无意义的失败案例。

致设计师（募）

2012-04-16T00:00:00-07:00

许多人从小都喜欢捣鼓点东西，写写画画，泥巴做的玩具，拆掉又装上的收音机。一些人很幸运，成长之后一直忠于自己的兴趣，最终成为满足体面生计的职业。而大多数人则在父母、教育制度、社会压力三阶段压力之下，沦为职业系统的砖瓦，从此过着朝九晚五的日子。

关于设计师的印象，在我心中却从未变过。小时候看过父亲晒的蓝图，那一根根清晰的蓝色线条下对应出的房屋建筑，透露着说不出的美。没去多少次的公园，参天古树与顺势而建的各种园林，也让人有种说不出的美。这背后自然是设计师的功劳，我明白这一点时已经很晚了。

然而设计师也逐渐沦为职业系统的产物。第一次对这个有印象，是在大学期间承接的一个政府项目。项目快上线了，于是有了非常中国特色的领导视察。站在旁边，领导用肥嘟嘟的手指着屏幕，说，喏，这块，用红色，那块，用蓝色。我看这个字有点小嘛，改大点。伴随着旁边一堆的叫好声，你捏着鼻子默默的改掉这些，然后再也不看第二眼。

第二次对这个有印象，是在第一家公司，新招了一个美工。那个时候我已经喜欢自己做界面了，但也仅限于用HTML/CSS来重现软件界面。听说来了个MM美工，很是高兴，于是颠颠的跑去，看看能不能学到一招半式。我去的时候美工很忙，忙着把公司网站加个新闻，改个样式，印个说明书。后来去的时候还是很忙。有一天我在她旁边看了很久，发现她只用Fireworks把图片切成圆角，然后嵌到HTML Table标签中，FTP到公司网站就完事了。有时也会从网上弄点转来转去的Flash，用盗版的Flash软件把里面的文字改改，也继续传上去了。

很失望。

人们说，生活中不是缺少美，而是缺少发现。而我认为这是屁话，生活中就是缺少美。比如我一次又一次的诅咒东直门机场快线脑残的设计——明知道都是有行李的人，候车站台只有2米宽；车厢里走道像飞机一样只能一人并行；西直门如同迷宫一般令人绝望的各种换乘；西安新软件园那个极其山寨的、用红色的隶书写上的XXX商务酒店；至于在中文互联网领域，飘来飘去的广告，密密麻麻的链接，毫无设计的配色，这些都令人深深的怀疑。生活中就算有美，也是少得可怜。

而我相信，背后的一切，是有设计师的角色存在。或者他们被毫无品味的老板指挥者，或者他们被无数的工作堆压着，或者他们妥协于某个委员会；或者他们本身，只是听说设计师挣钱，机械的完整了这些工作。仍记得03年开始去北京闯荡，那时各种IT教育机构叫嚣着，来XX培训，年薪10万！如今房价都已经翻了好几番，CPI翻了好几番，他们仍然叫嚣着：来XX培训，年薪⋯⋯还是10万！软件行业如此，设计行业料想如是。

而我坚信一些东西。

美工只是一个阶段，不是一个职业。重复对于设计师而言是不可忍受的。设计师持续追求技艺创新，除此之外，还承受超于常人的生活体验与情感体验，从而产生出充满人文关怀的设计。那些流传悠久的设计从体现出来的人文情怀，是设计师对真实生活不断反思锤炼的结果。优秀的作品一定是对外的，除了视觉上的美感，作品所传达的意图应当充满灵魂，代表了设计师自我与社会的融合。

这是职业化的对立面。职业化恨不得将这个原本完整的过程拆的零碎，从而产生更多的头衔和职位描述。美工，初级设计师，高级设计师，设计总监；界面设计师，工业设计师，交互设计时；广告设计，平面设计，动画设计等等。职业化固然有存在的必然，但我仍然相信这些只是阶段，而非一辈子的标签。追求美，追求品味，追求极致的设计，是区别设计师的关键。

目前我在设计一个新的基于Web的产品。他们把这个角色命名为产品经理。我也在写代码——他们命名为程序员；也时不时要查看系统日志，看看是否运行正常——他们称为系统管理员或者网管；也需要听取用户的反馈，解答使用问题——他们称为客服。并不在乎头衔是什么，这些工作的目的是制造伟大的产品，为数以万计的用户提供服务，而在此之前这些用户要忍受昂贵、粗糙、丑陋、低效的软件工具。我需要帮手，一个真正的设计师。如前面所说，你需要具备高超的审美和Graphic Design技能，不轻易妥协。目前状态下，具备软件界面设计/Web应用设计能够立刻与团队一起工作，但如果你设计能力非凡，学习能力飞快，你会有充分的空间来融入团队。我理解审美是长期修炼的过程，因此你最好拥有多年的经过证明的设计经验，我不是学历的粉丝——早就见过因为艺术可以减分考大学的突击两个月学画画的了。

你参与的软件将会改善数万人的生活。你会与顶尖的程序员一起工作，他们会与你讨论甚至争论，但他们最终能够实现你的任何设计。你会使用最大屏幕27" Mac电脑。你会体面地使用正版软件，包括昂贵的Photoshop。你会拥有充分的设计空间。不必朝九晚五，虽然偶尔需要工作很长时间。

最后，最值得一提的是，你的名字，与其他程序员一起，会被显眼地写在这个即将改变数万人的软件里。

想要充分的设计空间，想要改变这个世界，请给我发邮件：mechiland@gmail.com