陌上清溪

■玩笑■

时光逆流。竟得穿越。
月夜唐朝。禅房幽径。
还是那个贾岛，那是那头驴。
难得月朦胧鸟朦胧，不由得让人诗兴大发。
“鸟宿池边树，僧推月下门。妙”
“鸟宿池边树，僧敲月下门，甚妙”
“此一推一敲，孰优孰劣？孰劣孰优？愁煞”
酸腐的书生又在斟酌词句，却不想撞上了大和尚。

“贾施主又何必自寻烦恼，且看老衲”，说罢，
那和尚取出手机，左右上下点了三下两下，缓缓念道“鸟宿池边树”
不多时，手机娓娓传来一句“鸟宿池边树，僧敲月下门”
“妙哉！”瘦岛已然五体投地。
却见那和尚合十笑道“自古文章天成，老衲今日仗这‘安卓书童’妙手偶得，惭愧惭愧”，
说罢扬长而去。

■缘起■

用这样穿越的开头其实只是为了营造一个跟“安卓书童”较为贴合的意境。
安卓书童是清溪近期进行安卓语音识别实践的一个副产品。
这篇文章主要想谈谈期间的种种体会。

■历史遗留问题■

跟密码泄露一样，很多东西都存在着历史遗留问题。
我这个语音识别的历史遗留问题大概没有范先生的那样早，大约在一年以前形成。
当时我想做一款即时会议记录应用。
在我的想象中大概是这样几个应用场景：

团队里一群人坐在一起开会，说话人的声音传递到手机上，
程序实时地做语音识别，转成文本，进而存储。
虽然识别的结果必定存在大量误差，但是即使加入了最后的人工编辑环节，我觉得还是能够大幅提高生产力。
它能够解决快速记录会议内容要点的问题。

也许上述这种场合在现实来看必要性并不是那么强，
那么再考虑一下这种情况大概会有所改观：
大礼堂，大教室，前面的发言者拿着设备侃侃而谈，
字幕就在大屏幕上汩汩流出。
它能够解决后排人员听不清的问题。

可能你还是觉得这个想法太傻逼，
那么再看看这种场景：
一群外语白坐在高新园区的咖啡厅里听白佬讲ppt，
即使老外手舞足蹈热情高涨，下面的感觉依然是鸡同鸭讲。
如果这个应用能够实时地获取发言者的文本，再传送给翻译引擎，再变换为母语文字输出，
即使机器只能翻译出傻乎乎的句子，但是在不需要绝对精准的场合，我想对于泛泛理解应该是够了。
它能够解决异语种交流问题。

■尝试过程■

思路基本是明确的。
所谓的语音识别，基本就是做周波数曲线匹配。
一方面要具备相关的声学知识，另一方面更重要的是要有相对完备的语料数据库。
很遗憾，这两方面我都没有。我只能站在巨人的肩膀上。

针对语音识别可选项有以下几种方案：

科大讯飞（针对中文）

谷歌官方（多国）

日本Julius（针对日文）

ispeech（多国）

下面逐个谈谈体会。

⇒科大讯飞
中文识别十分精准，效果好（讯飞最早是中科大学生的创业公司，我觉得技术是过硬的）。
国内本土做语音识别的似乎是它一家独大（原谅我的孤陋寡闻如果还有更好的请给我留言）
为了减轻服务器连接压力，一个连接超过30秒会强行断开（须重复启动），好在api暂时没有调用次数的限制。
当前android的api接口还不够丰富。用它来做会议记录，需要自己在断开后重新检测语音然后开启连接。
而且，识别一次，平均起码要3秒钟甚至更多。只能自己做buffer来缓存输入的语音（很不好实现），
另外每次一断一连就有遗漏字句的可能，丢包太严重了。
另外，有时候人正在说一句话你给断开了，切句不对，识别率大打折扣。
这个还可以忍，毕竟算法的问题可以自己慢慢调教（我目前的成果基本是失败的）

最致命的是讯飞的服务器似乎非常不稳定（可能是服务器压力过大？）。
我在2g网络和WiFi网络下进行的测试。2g偶尔成功，WiFi时常失败。
2g不快是可以理解的。WiFi缓慢是值得批评的。而WiFi接入经常连接失败则是不可原谅的。
网络服务器状况导致应用极不稳定，所以现阶段用讯飞的api来做应用，个人不认为是一个好的选择。
撇掉服务器的因素，用讯飞的api有一个额外的便利之处：
将应用部署到手机上大概不需要顾虑安卓系统的版本，也不需要安装额外的插件，只需要确保网络连通（所有必须的东西都打在sdk里了）。
而谷歌的api就比较麻烦（要求你手机系统高于2.2，要求你手机安装voiceSearch。这绝对影响用户的胃口）

⇒谷歌
当然，讯飞好并不意味着谷歌差。
这篇文章介绍的对比结果跟我的经历大致相当，可以看出来并不逊色。
google的服务器稳定这是一个强项。
用谷歌的api来做会议记录同样面临上面的问题（缓存音频，队列请求发送控制），
事实上，谷歌的博客公开表示当前的api还不适合连续多句子语音识别。（到这一步我知道会议记录应用的想法暂时是不可能了）。
另外重复一下， 谷歌的api需要你系统2.2以上并且安装了voicesearch（我的乐phone是绝对没有的）

⇒Julius
当初主要想对应日本市场，所以对日文的识别技术也进行了调查。
这是由京都大学早期开发的一个项目，opensource。
暂时没有android的版本，不过linux下的支持完备。所以我想大概可以加工成so文件然后用NDK来调用（未尝试）。
如果得以改造成功，这个不需要网络连接，而且可以自己控制断句处理。应该很有魅力。
因为是开源项目，我认为每个有志于日文语音识别方向的宅男都应该好好研究一下。地址这里
btw，如果是想学习英文的语音识别，可以关注这个开源项目。SPHINX卡耐基梅隆大学牵头。最新版本已经完全用Java改写，易读。

⇒ispeech
这一家api我并没有尝试。
不过看了它的demo，在语音合成方面效果很好。
说是可以支持语音识别。具体没有研究它的sdk（移动设备版本的sdk是免费的）。

■为什么做了唐诗机器人？■

从实践来看，目前我还很难用这些api来实现一个像样准确的实时会议记录应用。
当前的api主要特点适合于单句的（比如发个检索关键字，发个短信），允许等待的（3-5秒视网络状况而定）语音识别。
而且说话要跟手机靠的近，稍微远一点就不辨牛马了。
于是思路转回来，想想有什么互动形的idea可以依赖这个来实现呢？
以下是我当时想到的几个场景(当然大部分都是天马行空，不切实际的)：

语音计算器
类似夏天我曾经给推土机机器人开发过的命令行计算功能，只不过这次改成用嘴说。
识别数字和操作符以后，转成传统的计算处理。
它能够让你在计算时解放你的手指。
当然弊端也是显而易见，识别一旦有误，则可能酿成大错。这种东西意义不大。玩玩而已。

语音交互式读心游戏
很多年以前接触过一个网站，连续问你20个问题你只需要回答是或者不是，然后它能猜出你心中所想。
虽然原理不复杂，但是游戏讲究的是趣味性。
后来ios上的这个应用其实是一样的原理。
微软研究院的这个也是。
只不过我想改成语音的。这个要点在于后面的数据库以及Question的设计，做不来，放弃。

歇后语机器人
这个相对简单，搜集大量的歇后语存入数据库，玩家说出上半句，程序识别以后，
检索相应结果，然后取出下半句，语音合成，反馈回来。
比如，你对着手机说一句“老太太看地图”，
两三秒后，手机对你说一声“这是哪到哪啊”（配合讯飞语音合成的东北口音，应该很有趣吧？）
这个想法存在的几个问题是：
⇒歇后语的语音识别不准确，很多语句都不是常用的，对于api识别准确率有太大影响
⇒资料库的构建不容易，全国各地歇后语那么多，如果不够完全，用户试了两次没结果就会丧失兴趣了。
⇒要做的好就需要进行模糊检索，比如同一条歇后语不同地区的人说出来用词不同，程序必须有能力分词，然后计算权值来选择最匹配的结果，而不是单纯的字符串正则（这属于搜索引擎的技术了。。。）

唐诗宋词机器人
这个跟歇后语其实差别不大。但是回避了几个问题，
首先，唐诗的数据来源（唐诗三百首，全唐诗都非常容易获得），其次，各语音识别api对唐诗的识别效果都比较准（看天极网那个测试可见一斑）
当然，模糊检索的问题依旧存在。

我爱记歌词
旋律响起，突然有段歌词等你来填，匹配成功了就加分，设置花样不断挑战达到游戏效果。
这个仅仅是胡思乱想的。因为语音识别对于变调的语音（唱）好像根本不给力。
虽然有哼唱检索技术，但那是旋律，不是歌词。
很遗憾，幻想模仿《我爱记歌词》节目中那样让用户自己在手机上玩，当下还是有距离的。
调查也不是没有收获，发现这样一个网站（爱吼网），挺有意思的。

幼儿单词教育
把这个功能做到幼教软件中，出题考小朋友。
比如屏幕上出来一只熊猫，就问小朋友这是什么，
小朋友说“panda”，机器就发出一句表扬之类的，否则再鼓励。
等等。这个还是比较靠谱的，个人认为。语音交互是最符合人性的交互。

■语音合成怎么弄？■

说了这么多，基本就是下面这样的流程：

人发出声音⇒机器识别为文本输入⇒处理后输出文本⇒文本结果语音合成输出反馈

所以在开发中语音合成也是必不可少的。下面也简单回顾一下。
当前安卓上比较方便的以下两种手段，

利用TTS语音包本地合成

利用网络api远程合成后传输

同样分别详细介绍一下。

利用TTS语音包本地合成
这是比较主流的方式，也比较符合设计规范。
但是前提是用户需要提前安装语音合成包。
常用的大概目前有如下几种
⇒SVOX（多语种）
⇒Pico（似乎不支持中文）
⇒KDDI的N2（日文）
⇒讯飞（中文，不过官方说没有免费开放这个离线包，虽然民间早已流传）
⇒手说（中文，火鸟曾经就用这个，效果很差）
安装TTS的优点是coding简单，但是部署麻烦（需要用户安装并设置了相应的语种），我个人不是很喜欢（因为乐phone默认是没有的）

利用网络api远程合成后传输
说白了这种方式就是向远程服务器提交一个请求，处理之后再返回一个音频流。
对用户来说比较简单，无需多余设置（只需要网络连通），
但是coding相对复杂一些（需要建立http连接处理，然后对音频数据接收，再调用播放）
有以下几家服务：
⇒爱立信实验室的TTS API（目前只支持英文）
⇒ispeech同我上面介绍的，这家的合成效果非常好DEMO
⇒JaTTS（日文）
⇒谷歌翻译（但是官方似乎从来没有公布过这个api，所以个人认为这个是没有保证的）

泛泛的写了这么多，该memo的也都梳理了一遍。
从这段时间的体验来看有这么几个体会：

⇒不要一直用嘴去说，所谓的交流和讨论其实都很空洞，
你要是觉得可行，就去实践证明一下。若是证明了不行，再想别的主意。
掌握一个东西，理解一个东西，讨论一百次，看书一百次，也赶不上实践一次（话可能有点夸张）。

⇒想象中的东西，往往和最后的结果大相径庭。
很多时候，你想的是A，结果出来的却是B，不试不知道。
多碰撞才会有多灵感，多尝试才会有多收获。

⇒编程技术尽可能跟具体产业领域结合才好。
技术存在的意义在于解决现实问题。或改善生活体验，或提高生产力。
还是那句话，
如果技术不能解决掉什么，那要么让它进垃圾堆，要么回象牙塔。
（完）

■背景赘述
一直在做事，这次决心写点什么东西。
事情从去年冬天说起。
当时大约11月份，KDDI的新一款安卓手机开卖（型号不记得），
请了Ladygaga做代言，满车站里都是相关的巨幅海报。

我开始接触android这个概念是在2008年，当时工作不太忙，
有事没事业余经常在新小岩的住所里用youtube看google日本的那些andr讨论会视频。
觉得好玩很极客。
感兴趣不过没有认识到这会是一场革命。

玩着模拟器和sdk，不觉得是什么太复杂的东西，很明显这玩意的制胜点在于idea。
我的Java背景令我可以比较轻松地写一些简单的应用。
起先以为蛮庆幸，不过随后我认识到同我相似的人有千千万。这是一片红海，别争了。

但是去年那一瞬间看到ladygaga海报时就有个感觉重新冲上来，
“It’s Android Time！”（事实上这话当然值得商榷，不过当时确实如此认为）。
越来越多的厂商支持，andr之势好像地下压抑许久的岩浆终于喷射出来。

正好我们会点什么，正好我们又想玩点什么。
有美工有程序。还想玩安卓，还想进蓝海，我只能想到先搞个业余休闲游戏开发组（不敢想什么工作室）
其实是不知天高地厚，我们这几个人，开过论坛，搞过网站，送过鲜花，卖过门票，
说到做游戏也只是我第一份非正式工作在一家小公司做过一年的游戏程序员（VC++）。
那不管怎样，去年11月份，小组还是成立了。四个人，俩美术俩程序。
名字很土鳖，叫做T4Roid。
（事到如今快一年，只剩两个人。期间陆续一人往北京发展，一人退出。
个中波澜，且按不表。）
OK，很长。这些是背景，交代完毕。

■失败的第一弹
成立以后基本是在磨刀练枪，没有出作品。
因为我们的出发点是业余玩票性质，无盈利压力，不对股东负责，不玩了就撤。
记不清几月，好像是4月？校长南巡遭遇鞋击。
我们觉得这是一个好题材！（愤怒的校长？）
下午被鞋袭，晚上我们就开始画图了。
那一个月很充实。周末最快乐。
全天凑在一起，商量怎么干，人物什么形象，关卡怎么设计，代码怎么写。
刚开始都在咖啡店里弄，后来我们觉得成本太高，而且大连的咖啡店没有IT氛围：（，
有家干嘛不转移到家里去（这里要感谢小亮提供的场所，btw，泉水很漂亮很宜居）。
碰撞检测，物理模拟，人工智能。。。都一一实现，
7月份才勉强把demo弄好。距离想象中的“游戏”却还有很长距离。
做下去到完，起码还要两个时间。那时谁还记得校长，谁还会对这种山寨作感冒？
第一次做，不成功。
不成功的因素在于太多的技术摸索和验证耽误了时间。
但是练手的目的已达到，仅作为一个demo，它是优秀的。
出来的demo后来有几次用来对外展示团队实力，反响还好。
实话实说，我个人对于团队第一次能达到这个程度已经满意。不敢说八十，七十分绝对有。
（这里诚挚感谢期间提供友情测试的推友@popeyepluto ！）

至此，随着7月下旬我的马来西亚之行，第一弹宣告失败。

■卷土重来第二弹
这些年我主要靠着做外包为生，给公司做，合适的时候也自己接。
养成一个恶劣习惯是，看到有项目来就蠢蠢欲动。
几个月前，技术群里有北京朋友要发个包，内容是山寨这样一款flash游戏到手机上。
我自然想接，但是看来看去，没头绪哇。
但是觉得蛮好玩，会有市场，不妨自己细细研究一下。
昨天开始决定真的做了。
我不希望只在结束时候再来个像第一弹式的总结带过。
那样的话，或成功，或失败，都只会是一句空洞结论。
牡丹绚烂，花开过程想必更美。
我想记录这过程，开发工数，技术课题，大约成本估计，等等若干。
当然可能同样会中途宣告失败，也可能会浴火凤凰（渺茫と思う），都要不断更新。
留与第三弹作前车之鉴（かな？）
也许，某个时间点再回头看这些文字会觉得像笑话。
不过，当时每一步就是这么想，这么走的，不论结局如何，应该写出来。
这篇博文的初始目的就是这样。
OK，似乎，这里才是背景的真正交待完毕。。。
==========================背景分割线============
8月23日
6小时 研究metaball实现算法
学术资料1
学术资料2
学术资料3
8月24日
4小时 将metaball算法移植至andr，效率非常低。fps开始为46，
几秒后骤降为0.5.画面一顿一顿，完全没有可行性！可能要考虑位图叠加的方法。
发个截图以纪念这将要被抛弃的算法。


8月25日
3小时 参考actionscript实现的利用位图叠加实现的metaball算法
8月26日
4小时 企图移植，未成功。理由：对andr底层处理位图相关技术不熟悉，需要更多时间理清思路
参考资料群
参考资料2
8月27日
周六。听一个安卓的培训，收获就是恍然大悟，遇到问题基本都可以从demo的src中去寻找答案。
8月28日
周日。4小时。学习apiDemo中的graphic部分。
8月29日
3小时。采用canvas的方法叠合渐变位图，效果不错，速度很快。
截图留念

8月30日
5小时。企图利用微云框架的box2d来整合位图描画的方法，刷新效率极低。失败。
后转用surfaceview+bitmap方式，为三种颜色分别建立bitmap，然后叠加。
速度奇慢。此种思路不得法，非另辟蹊径不可。明日起暂歇。
截图留念

从未有过这样近距离的感受灾难。

很长一段时间我一直觉得地震是离我们非常遥远的事。
虽然学生时代念的课程里也有许多关于震灾的记录和介绍，
却总觉得那不过是些书本上的东西，是历史，是和现实生活基本不搭介的。
后来这些年行走日本，大大小小的晃动虽也经历不少，
可仍未感到地震给生活带来太大的影响。
那些令人发指的大震灾，近年来尽管时有发生，
只因为要么发生在外国，要么发生在外地，
又往往在媒体的误导下，地震被变成了一串数字，一个版面，一些捐款。

可是这一次真的不同。
１１号下午约摸两点五十分左右（可能不确切），办公室大楼开始摇摆。
左右，上下，横波，纵波。头晕。
折腾了近半个小时。之后就看见附近的大楼起火，浓烟滚滚。
远处空地早已经布满黑压压的避难人群。
再后来又看见遥远处火光漫天，不时有燃烧气云腾起。
后来知道那是油库炸了。
直升飞机开始在空中盘旋。
消防车开始汽笛长啸。
所幸的是，没有一个人慌乱。
再后来，海啸的事情。核厂的事情，大家都知道了。

回家的时候，平时乘客稀疏的巴士站已经排起长龙。地铁全线关闭。
步行回家。路上全是身着西装的职业男女在行走。
颇有『万人大徒步』的壮丽感。
这一切，似乎就是将银幕上的剧情生生地复制到现实中。震撼。

震灾已经过去七天。
东京的办公室今天依旧昏暗，为了保障救灾电力供应，
能不点的灯都闭了，能不用的电都掐了。
偶尔一两次的余震，渐渐淡化的辐射流言，陆续恢复班次的电车，
首都圈差的只是物流。当然还有电力。
恢复当然是需要时间的。职业关系，清溪持有一份材料，
零售业联合会的关于各大超市，物流的恢复时间表。
不能不被日本人的效率和团结所刺激。
据说，在北部灾区，政府的重建计划上细化到每一条道路在哪一天的几点恢复开通。

虽然超市里的食品货架依旧稀稀拉拉，居酒屋大多也是门可罗雀。
平日璀璨的高层建筑，如今只是象征性地射出几缕昏暗的微光。
救灾要务，其一在于稳定人心。
大灾过后，没有谣言，没有神棍，在当今的世界上也绝不能说是一个正常的社会。
三流的媒体喜欢危言耸听，媚俗的观众又恰好绝不接受平淡的剧情。
苍蝇叮上臭蛋，自然是如痴如醉。
可是如果我们以为这就是世界，那就是一种悲哀了。不是吗？

『上野的樱花烂漫，东京也不过如此。』
鲁迅先生的原话我已经记得不够确切，唯独这景象一直还印在脑海里。
相信很多人和我一样，最早的关于日本的印象，多少是受了些鲁迅作品的启蒙。
而昔日鲁迅先生留学的仙台市，这次就是重灾区，让人深感唏嘘。
网上传说东北大学的鲁迅纪念堂倒是依旧完好，不论真假，多少也算得一个安慰吧。
灾难总会过去，家园总会重建。只要活着，就是希望。
まじめにいきろ！生还者一定要好好的活下去。
我在这里，用最虔诚的心，愿逝者安息，祈愿灾民能尽快从悲痛中走出来重建家园。
也向那些救援部队和福岛抢险的英雄们，表达最深敬意。
衷心的希望救灾工作早日取得胜利。

时间走到这里，年轮又多了一圈，上面挂着一个标签：2010。
年末的时候，依照惯例来做次回顾是个必修的功课。而这也就是此篇博客的由来。

忙忙碌碌是这一年总体的印象。
一月份在大阪过的新年，二月份系统上线忙的不可开交。
四月份到六月份开始在大连也是紧锣密鼓（这个在《七宗罪》有提过）
随后在东京，现在还能想起来的只有窗外那片竹海了。以及若干首不象样的律诗。
十月回国。转而十一月又回到大阪。
年底才可算松了口气。

这一年在个人进步上有什么收获呢？
最大的应该是自己在时间管理的能力上的提高。
怎么做，何时做，分多少阶段做，多少人做，控制这些的能力比以前好了很多。
强大的压力下你必须很好的安排时间，这就是理由。
包括自己业余的学习，以前是漫无边际，今天有时间看两章，明年翻一页。
总想着反正是业余时间不当害。
现在对于业余的学习我也有计划，效果很好。
对于想了解学习的知识，先列出一个纲要，然后预估你的未来几周或者几个月的业余时间如何。
（几周就好，时间线拉太长准确率会降低不少）
然后考虑好浮动的因素，像安排你的项目进度那样去安排学习时间。
每日check，或者每周check。当计划可以量化以后，进度和质量都会飞跃。
朋友们可以借鉴。

获得了一次公司内部的什么技术贡献奖，印象中好像还没有人拿过。
说不清楚，也许是为了安抚员工情绪而发的这个奖，感觉政治性的意味相对浓厚一些。
但是我不care那么多，你都敢发，我还不敢领？
另外，八月份原来自己接了一个项目，门户+邮件系统，报价8000.
对方允诺。结果后来几经周折，别说8000，到现在连80都没赚到。
这个以后再延伸，暂且记录在这里。

在技术方面，自己perl水平的进步还是比较稳当。
夏天时候每天对着黑屏服务器无聊到极，写了一个perl版本的命令行俄罗斯方块，
perl版本已经搞的差不多，当时有一定的成就感。
计划陆续推出python和ruby版本，但是一回国后这个事情就搁浅了。

推特玩的比较猛一点。这不是好事情。
大部分人围在上面只是浪费时间，别无他用。
其实该联系的人都会联系，犯不着依靠什么社交网络。个人意见，可能稍显极端。
#twituji『推土机』大约持续了半年，陆续搜索出许多居大连的推友。
因为看到这一层功能，便开始有了构建大连推圈的想法。
但是从实践来看，这个事情的意义确实不大。
挖那么多人出来，但是兴趣不投，共同语言没几句，徒增噪音而已。
如果硬说这个东西有什么看得见的意义，恐怕只是在区域性新闻的传播上能更快捷广泛一些。
比如11月份软景e居起火事件,事发不到5分钟，图片，视频，我已经全部看过了。
若是换作其他渠道，这是不现实的。
这也是我有意建立其他城市列表的原因。
当然，我也食言了：原承诺要在年底做出20个城市列表。这个只能等明年再看了。
又比如前几天我想了解一个事情：『南京大学的研究生非日语专业二外用什么教材』
我的做法是，找到nanjing列表，然后找一个bio南京大学的推友，问他，请他帮我扩散消息。
这不是很好么，这也可以说是SNS问答系统的一种模型体现。著名的『Quora』不就是这样么。

再说说技术。
曾经一度沉迷过python，ruby之流，
很多人大概跟我一样，接触并愿意了解它只是是因为这个圈子比较小众，比较极客。
至于你要做的事情是否合适用它来做或者它的特性是否符合你要做的事情则考虑较少。
来年我应该不会在这方面花太多时间。
我还是比较实用主义。不因为它炫而去玩它，不因为它酷才去玩它。
一个技术领域的基础扎实以后，转型或者上手其实应该蛮快的。（可能这句话有待商榷）
兴趣的激增点是android平台。
事实上这方面我从08年就开始跟进，但是还真没有写出什么像样的东西。
来年的主要在这方面发力。
跟小亮一拍即合成立了工作室，主线是android游戏开发。
虽然未来不明朗，但是先干再说，功利性不强，只是对我们自己思考的一个实践。
最近什么所谓的『分析到瘫痪』不是很流行么，确实，小团队做事分析太多所谓的远景其实是扯淡。
『言之必行，行之必果』，是古训，也是小团队制胜的要素。（我是这么认为的）

在家庭方面。小孩挺好，天真活泼。有几次发烧，我这个做父亲的都不在身边，很惭愧。
夫人准备考博，压力也很大。有时候两人也吵架，太不应该，男人应该多担待一些。

另外，公司业务上，明年可能是一个冬天，具体怎么样不知道。
你晓得，外包这玩意去年签今年的单，今年接明年的单。
如果是今年还勉强OK的话，也是去年签下来的，但是从现在的形式来看，明年估计好不到哪里去。
无所谓。

前述：11月中旬，参加国际基因工程大赛（iGEM）的一个来自东京大学的小组（iGEM 2010 UT-Tokyo）实现了一种利用大肠杆菌来解答数独题的方法。他们在博客上发表了系列文章，本文是参考其原文而做的中文翻译（原文版本时间2010-11-21 (日) 1:10）。
为了让读者更好地理解本文，我先简单介绍一下数独的人工解法。首先看下面这张数独图

这是一个4×4的数独（虽然我们平时玩的大多是9×9）。解题者需要将1，2，3，4这几个数字分别填入各空白方块。条件是保证每一行，每一列，以及上下左右四个2×2小块中不允许出现重复数字。
先让我们来解[1-1]方块的值（灰色方块）。
>发现同一列的[1-3]方块已经被填入数字1，根据“同一列数字不重复”原则，灰色块不允许填入1，备选的只能是2，3，4。
>同样，根据“同一行数字不重复”原则，亦不允许填入3（因为[1-4]方块已经用了3），备选只有2，4了。
>最后，左上角的2×2方块群中已经有了2，那么可以确定出灰色区域的唯一值：4。
[1-1]方块解出来以后，我们可以用同样的分析手段，判断出[2-1]方块应该填入数字3。
以此类推，逐步判断，尝试，排除，最后就能将题解完。
但是你会发现，人工解答时只能按照线性的方式逐个列出备选，再逐个排除，遇到太复杂的情况有可能在中途不得不推翻之前所作的判断重新回溯。而该小组提出的大肠杆菌解题方法，则是利用生物的特性来模拟并行计算来实现解答过程。

———————–以下为翻译正文———————————–
数独详解
为了能够利用大肠杆菌来解数独题，必须确保大肠杆菌能够存储数独方块的数字信息，并且它们之间必须能够传递该数字信息。另外，在进行通信的时候，还应该根据数独方块的坐标来限制可通信的对象。（例如，代表1-1方块的大肠杆菌发出的数字信息可以传递给代表1-2方块的大肠杆菌但不能传递给代表4-4数独方块的大肠杆菌：因为1-1和1-2属于同一列）。我们提出的这个新系统，它用4种RNA（位点特异性重组（site-specific recombination）酶1-4的RNA）分别代表4个数字，利用RNA噬菌体在大肠杆菌之间传递这些数字信息。并且这种系统还能够限制大肠杆菌只能同合适的对象进行通信。我们把该系统称之为『信号病毒系统』（signal virus system）。

需要注意的是，这里的数独方块已经不使用空间坐标来表示，而是用不同的基因组来代替。在解答数独的过程中，也不是在划分为4×4方块的平板上进行，而是把所有代表各个数独方块的大肠杆菌全部放入一根试管中，令它们相互作用后再导出结果。

另一方面，按照『信号病毒』系统的设计，那些还没有算出其所代表数独方块数值的大肠杆菌，在接受到从其它数独方块传递过来的数字信息后，必须对传递过来的数字进行识别，判断，然后输出正确的数值。例如，某大肠杆菌以1→2→3的顺序接收到了别处传来的数字后应该输出4，若以3→2→4的顺序接受到数字的话则应该输出1，然后再向周围传递。必须注意的是，接受数字的顺序以及同一数字的被接受次数多少并不会影响输出结果。也就是说，按1→2→3和3→1→2或者2→1→3的顺序接受数字后都必须输出4。而按1→2或者1→2→2→2→1顺序接受到后还不能输出结果，换句话说，按照任意的顺序收到3种不同的数字之后，才能输出第四种数字。具备这个功能的类似开关一样的东西，就是我们所称的『4C3泄漏开关』（4C3 leak switch）。

★4C3泄漏开关
从适当的数独方块（同一行或同一列或同一2×2方块群）传递过来的数字，结过信号病毒（后面会详细说明）的作用，被送入大肠杆菌内。4种数字，分别对应于4种位点特异性重组（site-specific recombination）酶的信使RNA（mRNA）。mRNA被RNA噬菌体送入大肠杆菌内被翻译，这样就能够发现对应数字的位点特异性重组（site-specific recombination）酶。

至于4C3泄漏开关本身，则是由启动子（Promoter）和相对于开关结果输出的蛋白质编码区以及夹在它们中间的4个终止子（Terminator）构成。
而这4个终止子分别被其对应的4种位点特异性重组序列（sequence）所包含，这样，一旦发现了相应的位点特异性重组酶，该终止子就会自动被切除。（如下图示意）

一种重组酶就能够切下一个终止子（Terminator），这样的话，蛋白质编码区之前的终止子，当接受到0个数字的时候剩4个，接收到1个数字后还剩3个，接收到2个后还剩2个，接受到3个数字后就只剩下1个终止子了。（数独方块的数字未确定的大肠杆菌，最多只能接受3个数字。）

4C3泄漏开关，顾名思义，就是令某些 RNA聚合酶（RNA polymerase）在转录的时候遇到终止子并不停止而能够继续转录（即泄漏）的开关。

我们依照下面的要求来人工设计终止子：存在2个以上终止子的时候只能发现很少的蛋白质（几乎没有机能），而只有1个终止子的时候才能发现比较多的蛋白质（具备机能）。这样也就实现了当接收到3个数字以后，开关变成ON的状态（因为接收到3个数字后只剩下1个终止子了）。

事实上，终止子被切断的同时，与它其相对应的重组酶的编码区域也同时被切断。例如，重组酶1把重组酶1对应编码区切断。这样的话，按1→2→3顺序接受完数字状态变成ON之后的开关，就只剩下重组酶4的编码区域了。

开关状态变成ON，也就是意味着，噬菌体蛋白质的产生，和残余的最后一种重组酶编码区域的转录。上面那个例子中，唯一剩下的重组酶4的mRNA被转录（这个4也是该数独方块的解）。这样该数字就作为一个信号传递给了噬菌体蛋白质，就可以被RNA噬菌体传出大肠杆菌的体外。

★信号病毒
4C3泄漏开关在接收了3种数字变成ON状态之后，拥有剩下那个数字信息的噬菌体就在该大肠杆菌内被产生了。这是前面所谓的『只向适当的数独方块传递数字信息』信号病毒系统的主体部分。接下来说明一下怎么样限制数字信息只向合适的数独方块传递。

事实上，各个大肠杆菌，只对其所代表的数独方块信息对应的1套RNA进行翻译。利用反义RNA（antisense RNA）来对噬菌体所传递的mRNA阻止翻译。这样就可以令所有数独方块被噬菌体感染后，只读取那些合适的方块传递来的数字信息（同一列，同一行，同一2×2方块群）。不读取其实就是不翻译，也就不会产生对应的酶。例如，在代表1-1方块的大肠杆菌中，能发现代表1-1，2-3，2-4，3-2，3-3， 3-4，4-2，4-3，4-4方块的mRNA对应的反义RNA（antisense RNA)，所以这些方块传递过来的数字信息就会被无视。

而如果是合适的数独方块传递过来的信息，则会被翻译，生成对应的酶，再按照前面所述4C3泄漏开关的工作流程进行。

★结果观测
为了让数独的解题结果能很明显的表现出来，我们为每一个数独方块准备了观测用的大肠杆菌群。这些用于观测结果的大肠杆菌，除了自己所在数独方块对应的大肠杆菌输出的噬菌体之外，其余的都用反义RNA屏蔽了，所以它只翻译自己方块对应的大肠杆菌产生的重组酶。

在这些观测结果用的大肠杆菌内部，重组酶将荧光蛋白质编码区域前的两个终止子切断。这样就能够发现传入数字所对应的荧光蛋白质了。例如，假设1-1方块算出来的数值是1的话，观测用的大肠杆菌只会翻译重组酶1，从而将能够发现其对应的绿色荧光蛋白质。

这些观测结果用的大肠杆菌，被分别放置到一个4×4的观测面板上。在试管内的大肠杆菌解答出数独题之后，将试管的上层清夜（噬菌体液），分开放置到4×4的观测面板上。这样，在各个方块中的大肠杆菌内，可以发现解答出来的数字所对应颜色的荧光蛋白质，那么就能够观测出数独的解答结果了。（完）

一年前清溪就曾打算入手一台掌上阅读设备。
当时的考虑很简单，仅有以下几个要求：
　＞能够阅读pdf书籍
　＞抗造，使用寿命起码两年以上
　＞价格不能太贵
于是陆续间断地考察了几种方案，效果却不十分理想（见下表）

方案	缺点
智能手机	屏幕太小，看书难受。对pdf阅读支持差
汉王系列	要么设计太过古董，要么价格太贵 ※价格高于1200+本人不会考虑
其它国内厂商产品	鱼龙混杂，大部分其实就是一个大屏mp4而已
ipad	仅仅是看书，花4，5千块买那么个东西太贵
山寨平板	价格可以接受，比如国美飞触。但是感觉安卓平板技术不成熟，不想吃螃蟹
kindle	价格1200+，贵。另外不想去网上买不三不四的水货，不放心

于是抱着观望的态度直到今年夏天。
直到盛大开始推出锦书（bambook），定价999元。
实惠的价格加上盛大的煽情造势，很快就让我决定入手这款国产“kindle”。

其实回头看这个事情清溪有两个体会。
体会之一，我为什么选择了锦书？
无非两个因素，一是价格，二是盛大的品牌和它的造势。
平心而论，我并不敢期待锦书在质量上会比汉王产品好多少，但是盛大的市场营销相当成功。
先是搞了一个所谓的内测，请了很多名人来谈使用体验（拿人手短，谁会说它不好呢？）。
然后打出一个让你意想不到的价格：内测价格998，正式价格999！让你觉得真实惠，不是么？
这种营销手段跟新浪博客，新浪微博异曲同工。
在中国市场搞IT方面的营销就是这种手段好使。
从精英推广到草根，成功。反过来，从草根开始往上做，难。
比方说当初的饭否，做微博都做死了，最后只不过是培养了用户习惯为新浪微博做嫁衣罢了。

体会之二，国内的信息产业界创新能力差，基本就是对国外亦步亦趋。
老外有google，咱们这里才会有百度。
老外有twitter，咱们这里才会有新浪微博。
老外有facebook，咱们才会有人人。
老外有groupon，咱们才会有美团。
老外有kindle，咱们才会有锦书。
国内厂商的创新能力非常差。
但是因为我们市场的半开放性，这些国内厂商活得还不差。
只是从长远来看这是很危险的。不过是在步我们汽车工业的后尘。

书归正传，还是说说锦书吧。
■发货速度：不快
十一黄金周时候我在官网预订并交付定金。当时查看其排队系统显示我在一万两千多号。
最终于20号收到锦书。这其中扣除国庆假期，基本上是两周。
个人感觉盛大的发货速度稍慢。

■便携性：差
重量虽然很轻。但是因为屏幕使用的材质非常易碎。
挤地铁？别让人给挤碎了。
网络上有非常多案例，使用不当导致锦书的屏幕破裂。
（据说一旦碎了就要花400多块送回去修）
不过锦书有搭配cover一起销售，不知道那个能不能起到一定的保护作用。

■读书视觉体验：良好
因为采用的是电子墨水技术，不同于液晶原理，几乎不累眼。
和看纸质书基本是同一效果。
但是比较遗憾的是，只支持黑白灰度效果显示。对于彩色则是无能为力。

■续航时间：据说20天，到现在还未充电过

■文件格式：麻烦。
必须使用其提供的云梯软件转换。这是一个纯粹的二流软件。
另外它好像只能在windows上跑。
至于pdf方面的支持，似乎对于纯图片，纯扫描的pdf不是太好。清溪未进行深入测试。
对于caj这种国产文件格式，居然干脆不支持转换，吐血。

■TTS功能：汉语一般，英文基本不能听
似乎语音合成引擎采用的是安徽科大讯飞的方案。
略显生硬，要达到听书的效果，还有一段距离。
朱继盛（SDG首席技术官）说用这个给孩子晚上睡前讲故事，拉倒吧，我怕听多了以后小孩说话都说不好了。

■网络功能：失望
我没有3G卡，也没有wifi设备，只能用它说的第三种方式：USB接电脑联网。
但是很遗憾，直到现在我也没成功联网过。
不联也罢，因为网络即使连上也只允许访问盛大的云中书城！

■周边设备：保护皮套+太阳能充电器+专用3G上网卡 （需要另外付费）
■第三方扩展：不开放
虽然锦书使用的是android系统，但是目前不支持第三方程序。真是可惜了这么一台机器。

■售后：说实话，我这种人买东西很少考虑售后的。。。
■翻页速度 1秒。 ※非严谨数据，仅为本人主观评测
■开机时间 3秒。 ※非严谨数据，仅为本人主观评测
OK，最后该上图了。 ※拖动图片至单独一个浏览器窗口可看大图
==================图片和感想的分割线===============
■锦书外包装

■锦书屏保

■锦书背面※祥云图案，中国风设计

■A4纸尺寸对照

■锦书键盘

■书目录

■书目录2

■锦书看代码的效果（不能着色显示）

■代码中号字

■代码大号字

■锦书显示汉字（雅黑）※字体可安装设置

■锦书显示英文

■锦书网络功能

■互动 ※必须联网至盛大云中书城

■侧身接口

■侧身2

■无线网络开关

■数据线 ※图案是果壳电子的logo

谢谢你花时间读完这篇文字。
如果你正在考虑一款电子书，希望我的这篇文字能给您些启发。（完）

不知名的台风又带来绵绵细雨。
整日整夜地下，索性早早就上了床，看书，写字。
我一直都有开缝窗睡觉的坏习惯，下雨天亦不例外。
如此一来便可以听见外边细细碎碎的雨点声音。
人在一年一年变化，而这雨点声从小听到大却从来都是那个音调。
雨初下，尚在润物之际，声为滴沥，此时最为动听。
稍微大些，略显浑浊，声则改哒哒。
倘若要再大，就逐渐模糊，尽是噗噗之声，不剩什么听头了。
要遇上急雨时分，则是大珠小珠，嘈嘈切切，
尽管这本被用来形容琵琶女的琴艺，我看作为急雨的表现也不失贴切。

我走过不少城市，福州，厦门，上海，南京，大连，大阪，东京。。。
很幸运，这些城市的雨天气我都曾领教过。
东京的雨最为婆娘，一下起来就没完没了。
偏偏很多时候又下的不大，打伞不是，不打又湿，一如日本人的暧昧。
大阪的雨来的急走的快，倒很有关西人的风格。
大连不消说。大连的雨水感觉最差，一年也下不来几次，
好不容易来了一场，也是草草就收场，果然是个缺水的城市。
而上海的冬雨令我印象尤其深刻，
冷的深冬，毫无防备，忽然来一场冬雨，只让异乡客徒增无限寂寞。

凉快，清新，好睡眠，雨天什么都好，就是出行不便。
上巴士，进地铁，拎着伞，雨水还不时顺着伞面往下淌。
湿漉漉的车厢，好不难受。
再说TAXI，经过的每一辆都满客，好不容易来了个司机肯停下，
一听你说要去哪个旮旯，理直气壮地拒载（大连就是这样的），你有什么办法？
心想还是走几步吧，可是面对沧海乱流的路面，踩哪里是好？

小时候，常看到父母皱眉“又是落雨天”，
父母都是风雨里奔波的人，怎会喜欢下雨？
年少时衣来伸手饭来张口，又如何能体会那种烦恼，只是文绉绉地觉得雨天的美。
等到自己参加工作，也开始四处奔波的时候，真是有一点懂了。
所以，对雨天陶醉不已，大约全是那些衣食无忧的公子和小姐才能有的情怀罢。

前注：这是很多年前（大约07年？08年？）写在自己MSN Space上面的文章，
今天听说微软要变更其Space服务，才想起已很久不曾使用它，注册了帐号却不使用总归不太环保，
遂将文章导出，注销了MSN Space。文章贴于此，以作纪念。
==========================正文分割线================================
　　 《论秀外慧中论坛的倒掉》，感谢鲁迅先生。本文改自《论雷峰塔的倒掉》，谢绝转载。

　　 听说，5d6d的大外秀外慧中论坛倒掉了，听说而已，我没有亲见。但我却逛过未倒时候的秀外慧中，喽罗般的马甲穿梭于清冷的版块之间，稀稀拉拉的水贴充斥着那些静寂的地方，就是『秀外慧中』，大外周边论坛之一。

　　 『十四人在线』的真景我也见过，并不为佳，我以为。然而一切大外旗下的诸多论坛之中，我体会得为最深刻的却是这秀外慧中网。

　　 坛主曾经常常对我说，这坛子将来可是要做得大外周边第一站！早年留倭的浪人搭了论坛，天时地利，寒来暑往，不出几载竟已然独大。就是如今的『欢乐传说』。自古分久必合，合久必分，『欢』亦未能跳出轮回。适逢大外迁址，新旧更迭，必临人气流失之患。此来，内不敌百度新浪，海内校内，腾讯滔滔；外不御FACKBOOK，TWITER。更有扶桑MIXI虎视耽耽。。。前程堪忧，未来不美。培育人气数载，不过终为他人作嫁衣耳！『欢』之分崩离析祸起萧墙已可初见端倪，虽然尚无剑影刀光，潇潇四下却早已风生水起。坛主讲起来还要有趣的多，大约是出于多年混迹互联网的经验。但我没有那些往事，所以也不知道个中许多究竟是否这样单纯。总而言之，论坛就托载着这番愿景，发迹于5d6d，后来又生出许多的马甲来，这就是秀外慧中。此后似乎事情还很多，如『转载原创纠纷』之类，但我现在都忘记了。

　　 那时我惟一的希望，就在这坛子的振兴。后来我注册马甲了，到了秀外慧中，看见这稀稀拉拉的贴，心里就不舒服。后来我上上网，才晓得大外人不太常来这坛子，里边活跃的多半是NV的ID。那么，里边当然同大外不太搭介，然而我心里依旧不舍，依旧希望它振兴。

　　 现在，它居然倒掉了，则普天之下的网民，其残念为几何？这是有事实可证的。试到天涯问答，百度贴吧，凡有田夫野老，民妇村姑，除了几个脑残愤青非主流之外，可有谁不为秀外慧中感到遗憾，不为倒掉扼腕的？

　　 论坛时代大概已经要过去。纵是后来的SNS，WEB2.0，也要变成明日黄花了。这时候新起的坛子，还能有什么发展呢？那早期的『欢乐传说』，大约全是踩着机遇罢，–那简直是一定的。

　　 听说，后来的许多大小站长，年景不好，纷纷解甲归田，另途谋生了。思来想去，互联网是泡沫，始终不敢再碰，到现在还如此。秀外慧中的站长，大约心里只有着美好的梦，只可惜那时没有考察得这样深刻，或者也没有那个心态，却当是成熟的代价罢。

　　 当初，『欢乐传说』火爆于钟灵毓秀的大外之中，秀外慧中寄人篱下于5d6d。现在却只有欢乐传说独自欢乐，秀外慧中已然湮灭灰飞。莫非坛主建此论坛的时候，竟没有想到坛子是终究要倒的么？无奈。

以前每次我出差的时候，很少给老板写项目汇报，我觉得这些都是浮于形式的东西。
因为这个事情也曾经被公司说过。
只是，我想，七拼八凑的给你写一堆项目进度和RISK状况等等，你看了难道会有什么质的认识？
耽误彼此时间的事情我看还是少做的好。

与其迎合老板搞这些形式主义，还不如在自己的博客上静心做个反思，是吧。
所以今天的主题是对最近半年的这个PJ来个自底向上的总结。
为什么说自底向上呢？
因为这次我不负责带队，手下也没有人，我只是一个打酱油的身份。
以酱油男的眼光去回顾整个项目的前前后后，大概能够相对客观一些。

闲话不表，步入正题。

■项目背景
客户是一家大型地方银行。
因为是首次合作，倘若项目成功，客户日后必定持续发注，钱景乐观。
而如果失败则显然一切成空。
在IT形势尚未回暖的前提下，更加凸显了公司对于客户这种『有钱就是爷，有奶就是娘』的依赖。
换句话说，这是一个只许成功不许失败的项目。
或许是由于这种巨大的压力令后来决策层的风格日趋保守（激进意味着犯错概率增加），
导致了很多负效应。

项目核心为银行结算系统。
该系统客户定制成分很浓，业务独特，所以需要客户确认的东西非常多。
概要设计，基本设计，这些都要跟客户来回切磋。
因为这种背景，该系统并没有一个成熟的模型，
另外客户并不是系统架构师，常有犯错和误解的时候，
所以在开发过程中来回修改基本设计也是可以预见的事情。
（螺旋式前进，当然这些都是客观条件没有办法）

■团队状况
外包公司大抵都类似，每年都有一两个特别大的PJ，
而且这一年公司80%的收益主要靠这一两个项目。
加上如我前述这个项目的特殊性，因此据说部里是很重视，
挑选了许多精兵良将（据说相关领域作业经验丰富）。
清溪4月份恰逢前任项目结束未及休假，而他们正缺一个能打酱油的，
来公司一年左右，很多人我还尚未有过合作的经验，出于此目的，我便欣然受领。
最后主体团队成员状况大概如下：
按业务模块分了3个小组。A（4人），B（3人），C（5人）。
据我统计，平均年龄，30+； 平均月薪，8k+。
※此时回想，这么多大爷过来当小弟，项目失败似乎是意料中的事情。此为第一宗罪也。

我这个酱油男落在C组里，有时也兼职全项目的一些服务器脚本和数据库管理。
业务上，日方总部有一名经验者常驻银行客户现场，负责同客户一起制定确认式样，且称作M君。
另外大连这边有两名日本人常驻（且称作F君和Y君），本意是让这两人同M君配合，
把握式样的变更和指导大连团队的设计。
※事后证明这个体制并不好。因为这两人也不是太懂业务（理解不够深刻），
另外两个日本人第一次来这里长期出差，生活不能适应，工作也应该不会太上心。
况且隔着这么远，很多业务上的东西没在现场的确拿捏不准，
导致后来大连的团队要确认一些式样的时候，绕过这二人和M君直接联系。
A，B，C 3个Team，有时候M君一天要处理几十封的QA邮件，不疯也应该快疯了。
本来就是一个不成熟的业务系统模型，更加需要保证式样确认的及时性。
而F，Y二人不能发挥出其应有的作用，大连开发团队的业务指导基本上成了M君一人的工作。
沟通的成本增加，作业效率降低。
同时项目有随时中断的风险（只有M君一人能算的上是懂式样的，一旦M君倒下咋办？），此第二宗罪也。
同时，F，Y二君失去了代理职能，3个小组独立和M君沟通，
造成本来需要全局变更的式样（比如数据库某字段设计）常常不能全体及时修改。
前期打基础的时候缺乏协调全局的角色，造成后期模块对接时产生混乱，此第三宗罪也。

在管理上，大连3个PL，对本地PM负责，PM和F,Y而君一同对日方PM负责。

■项目过程回顾
2月和3月。大连方面派出5人左右（主要是PM和PL），同M君一同做基本设计（主要基于M君和客户的共识）。
所谓基本设计，就是各主体的机能模块已经有了划分，包括input和output，系统调度顺序，数据flow等等，
至于内部细节如何实现，只需简要考虑可行与否，具体留待详细设计作业。
这段时间清溪还在别的项目里，所以具体情况不详。

4月。人员全部返回大连，详细设计开始。同时一些之前残留的基本设计也在同步进行。
按照最初计划：详细设计周期为4月和5月上旬。编码制造从5月中旬到6月初。
单体测试和结合测试时间为6月份。
7月，8月到现场用客户真实数据进行综合测试。
9月正式上线。
看上去一切都很美，井井有条的感觉，但是。
详细设计一入手，发现按照基本设计所定义出来的系统来看，作业量不是一个月可以完成的。（仅我在的C组就有大约140本设计）
另外，这个时候发现基本设计的某些部分不合理，基本设计有一些也需要同步改动。
为了给新客户留下合作愉快的经验，总部下令必须恪守开发周期，没有商量余地。
那就得增加人手了。不知道是因为大家都忙（有这么夸张吗？）还是为什么，
公司决定去找外面协力来帮忙。
其中有一场面试是我参与的，主要考察脚本的编写能力。
当时有一哥们，什么问题都是跟我含糊一通，然后给我一句“这个功能用自带的函数就能解决”。
我有一下没忍住就问他用什么函数，
他想了想，说用的时候查查就知道了。
我看大家都是出来混的，就没太苛刻。（况且在大连想找到什么好的协力公司也是扯淡，我以为）
加上协力，加上内部调过来的人员。到4月中旬，项目组已经扩展到近20人。

以后来的实践来看，这批协力做事责任心不够，虽不能说没帮上忙，但是太有限，
做出来的东西很多不合格，反复review，反复修改，非常浪费时间。
再一个，做单体测试的时候，用的数据太随意，有点糊弄的感觉（临界值和一些特殊状况压根不考虑）。
尽管人手看起来很多，有用功却不随之正比，4月和5月项目成员几乎每天朝九晚九。
人力成本投下去，却没能够收到正面效果。
好的管理是人越多出力越多，而我们这次是人越多混乱越多。此第四宗罪也。

再说说6月份的事情。
因为人海战术的应用，总算，6月初制造完毕，开始进行测试了。
也许是疲劳了两个月的关系，项目成员心态明显不同了。
相当多的人持有一观念：6月份的测试工作不重要，糊弄糊弄就可以过去，
等7月8月去日方现场测试部署的那帮人发现问题再说再改。
这本质上是把问题推后，掩埋，越到后面肯定是越危险。
以我最近在现场的经验来看，A组的东西像几乎没有经过测试的。（一个SQL文件跑起来，还会提示某字段不存在，我不知道这些人在做什么？）
缺乏有效的品质管理机制（我不赞成组内测试，应该有个专门严格测试的小组才好，但是这次项目资源是个问题），
就像A组这样很多东西未经测试混水摸鱼，给后期工作造成了巨大壁垒。此第五宗罪也。

进入7月份，问题全部暴露出来了。
导入客户的数据，有些模块压根没法运行。
详细设计描述的结构和客户实际提供的不符，为什么导致这样？
因为做好的详细设计都是交给M君review的（F君Y君无法看出逻辑问题），纵然是神仙，一人也看不过来这么多，这么细。
疏漏不可避免，有些东西几乎是到了综合测试的现场敲掉完全重做的。

一再跳票。客户很惊讶。客户很生气。
生气的原因大概除了这个前期的品质太差令后期测试计划无法按时进行之外，
恐怕还有部分原因是出差人员某些行为细节的欠考虑。
客户是完全不懂中文的，但是和我们坐在一起工作。
某些人上班时间大声嬉闹，甚至发出爆笑。
客户听不懂中文，看你说话这么大声，表情这么夸张，他会怎么想？是不是会有种负面的情绪产生？
做事成败与否另说，做事的态度是你给局外人的第一印象。
项目如果做好了，可能客户也就忍一忍认为是文化差异，
可是你项目做砸了，人肯定就以此认定是你的工作态度有问题了。
现场工作，尤其是在这种濒临失败的项目现场工作，依旧说说笑笑，毫无自省之意，此第六宗罪也。

■感想
在现场常发现模块间的接口不对的问题。
双方总有一方要改，我认为这个时候应该是大局出发，两组协商，怎么最简单最快就怎么改。
但是现实却是小组之间推诿，你要我改我说那是你的问题我坚决不改。
没有一个全局观念，各leader都只想推卸责任。
按理说这些问题都应该在4月5月的设计阶段就调整好，那时候都干嘛去了？
小组之间几乎没有沟通。大部分人只知道做设计做代码，而不知道最后的目标是为了造出一个高效连贯的业务系统。
你做的东西尽管很多，可最后都接不起来，那不就是垃圾一堆吗？
PM这一点做的是不够好。起码在测试的时候，要先想办法造出一个模拟数据，来个疏通测试啊。

我还看到很多代码里加了注释，写着“此处要确认”的字样。
都啥时候了，还找谁确认去啊？

状况很恶劣，所以大家情绪都比较消极。缺乏一个正常的发泄渠道。
『带没带过项目啊』
『行不行啊，都啥时候了，还能有这种错误』
『你让他一个人整吧，出问题全是他的责任，跟你一点关系没有就行了』
『饼子，棒槌』
『反正我到点就走，就这么耗呗』
往往都是这种话语充斥着耳朵，这只会令你更加悲观，
所谓“与其诅咒周围的黑暗，不如点亮一支蜡烛”
项目的复杂度，管理的疏忽，各种条件决定了今天的这种状况，这已经成为了客观存在，
现在不是追究责任的时候，齐心协力把问题都克服掉才是首要任务不是吗？

还有一个很严重的问题。
可能上面是觉得到了最后阶段无所谓了，源代码居然都不采用版本管理，权限管理。
成员可直接修改共享目录下的源代码。。。

项目濒临失败，部里也非常着急，空降了很多高层过来督战。
问题是，这些人来了实际意义不大啊。
事实上，管理层来这么多人，下面干活的人往往会有怨言的。

最近在现场我看了很多详细设计书，找到好几个纰漏。
这些有纰漏的设计书大部分是男性写的。这难怪，写设计书需要心细一点，女性更适合这个工作。
即使你有review体制，也是不可能做到太高效的纠正。
最好的方法是用工具去生成文档，其次是分配给适合的人去做。最低下的方法是按成员人数平均分配。
当时做设计书的时候就完全可以分工灵活些，多让女性成员担当主体。
有极客精神的人多让他去负责稍复杂的模块的开发，不用你催他自己都会很用心去攻关。
而按部就班的保守派就适合让他去搞测试。
如何合理分配人员资源，这也是各leader应该考虑的问题。
你让善于游泳的人去爬树，特长没有办法释放出来啊。
而很多管理人员理解的项目管理似乎就是“分活，催活，加班”。

说了这么多。感觉自己其实挺二的。
谁会care这些事情呢？也许像我这样的loser才会关注这些罢。
别人不是照样混的很好吗？深得器重，公司有什么好处都少不了那几个人。
而每次失败的项目也少不了那几个人。
所谓的“精兵良将”，也不乏大部分骗吃骗喝的人（也许是术业有专攻罢）。
我们公司的PM没有实权的，仅仅是一个项目管理职能，
这是好事，也是坏事。在这次项目来看，就是一件坏事。
没有问责体制，成员眼里就没有权威。
项目做砸了又怎样？你又不能降我薪，不能革我职。
绩效评价给评低一些？我跟老板走的近一点，我就肆无忌惮了。

这些天有时候晚上加班后回家打开电脑收公司邮件，发现大连办公室发来的尽是一些嬉闹聊笑的群发邮件。
这个风气，这个组织的文化，可想而知了。
虽说人各有志，但是做事的态度这一点，这个团队里很多人是不合格的。
人说普遍情况下，工作五年后人的轨迹基本就定型，
对于这个平均age 30+的团队，是不能指望有什么大的变化了。
这不是一个技术团队。
可能是到了这个年龄的关系，很多人要给自己找到一把PM，PL的交椅。
所以学PMP的人很多，通过考试的人也很多，但是懂得管理的人很少（我并没有说我很懂管理的意思）。

我有时候问同事关于项目的想法，他们会说，管它那么多呢，反正最后责任又不要你担。
是，当然不用我担，我只是一个打酱油的。最多部长再去给客户下跪请罪罢了（也不是没跪过）。
但是团队是我们的，没有人去反思这个事情，大部分人总是一个观念：
认为今天弄成这个局面，主要就是前期总部和客户沟通不够的问题，
导致式样频繁变更，rework太多，管理层不会带项目的问题。。。
都是这副事不关己的心态，做事能做好吗？
这几年，KO，KTS，DE等等几个大项目，没有不失败的。
我承认《没有银弹》说的很有道理，软件系统的复杂性，很多时候你无可奈何。
但是。咱能不能先探讨完主观因素再去说客观因素。
这个样子，下次再来一项目，十之八九，我看还是要重蹈覆辙的。
不反思不总结不进步。此为第七宗罪也。

另，这次项目搞得#twituji 推土机没法持续开发，很苦闷。当然，这是外话，暂且不表。
祝各位朋友顺利开心。
（完）