为什么我们在细节上做不好?

最近团队遇到一个案例。看似很小的事情,但仔细研究起来,彻底分析,每一个环节都没做好,细节部分糟糕得一塌糊涂,最后导致一件事情的结果:完全失败。

经常有人在聊起公司的时候问我,你现在最担心的事情有哪些? 我当然会重点提到团队。不过在谈及团队的时候,我又最担心在「细节」问题上做不好。

细节就是竞争力,尤其是对小团队来说,小团队更应该注重细节问题。大一点的公司可以追究责任人,靠流程、靠制度,靠各级评审等等一系列的「成本」来提升细节能力。小一点的公司或者团队怎么办? 恐怕只有依赖每个人的能力和责任心了。

细节也是锻炼人的能力的地方,搞清楚每一个细节,将每一个细节涉及到的背景知识和技能掌握好,能力自然也就会得到提升。继而,着手做更大的事情也不会手忙脚乱。相反,做不好细节和小事的人,如果总嚷着要做「重要」的事情,做更有「挑战」的事情,这样的事情真的到你面前,真的能接住么?

为什么我们在细节上做不好?

对细节问题不够重视 一件事情到了自己这里,头脑中先入为主认为只是一件小事,是一件简单的事情。这样,当然就不会给予足够的重视。小事不一定不重要,小事不一定意味着做起来就简单。

对事情复杂度缺乏认知 不就是给客户写一封电子邮件么? 不就是用 HTML 写一个页面么? 不就是做一则横幅广告么? 那么,这些事情真的简单么? 为什么别人为客户写的邮件打开率更高? 为什么别人写的页面更容易被搜索引擎收录? 为什么别人做的广告转化率更好? 背后涉及到哪些知识? 不想研究一下么? 不能研究一下么?

对细节缺乏耐心 草草了事,应付了事,遇到问题马马虎虎,轻易得放过了很多可以让自己得到成长的机会。「这问题我没想过」「这事情我没遇到过」「设计稿都改过两次了」… 这类借口在任何一个团队都很常见。

缺少责任心 常常觉得自己这里做不好,还有别人会把关呢。担心什么? 可如果所有人都这么想呢? 「文案是产品经理的事情,关我甚么事?」如果你能对文案也有改进意见,谁说以后你就不能做产品经理做的事情呢?

主观上不认可自己的工作 就给我这么一点钱,要我做这么多工作? 问题是我们如果不多做一点工作,不提升一下自己,又怎么能多一点钱呢?

为什么细节上做不好? 不同人不同的角度还会有不同的看法。不过有一点我能肯定,细节不会决定成败,但做不好细节,一定会失败。

做好细节,百事可作。

EOF

此文作者:, 位于 Startup 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

扎克伯格的错误

今天业界热议的事情是Facebook创始人兼CEO马克·扎克伯格在接受采访的时候承认「专注在 HTML 5上面是他有史以来犯过的最大的错误。」然后,透露出来的数据是:用户浏览的 Feed 信息流是之前的 2 倍。

Facebook 最初使用 HTML 5 的主要原因是什么呢?一次开发,跨平台发布肯定是其中考虑的一个因素,当然,开发上可以做到快速迭代,这和 Facebook 的工程文化也是相符的。不过,这样实际上是节约了开发成本,获得了开发上的「速度」,这样做也牺牲了用户的体验上的「速度」,牺牲了「性能」。

为什么 Facebook 过度在移动上压注 HTML 5 是不对的?最大可能的原因或许就是「性能」的问题,没有更好的速度就没有更好的用户体验,而用户体验一直是扎克伯格最看重的东西。

扎克伯格从 Facebook 创建之初就认识到,对 Facebook 这样的的网络服务而言,「性能表现就是关键。假如向用户传送新页面的速度开始减缓,那就是致命的一击。」从技术的角度看,Facebook 一向在网站优化上不遗余力,无论是 BigPipe 还是 HipHop for PHP, 这些不遗余力的优化实践以及技术创新为 Facebook 带来了绝佳的用户体验,而移动端押注 HTML 5 则恰恰是无形中背离了 Facebook 的这一准则。

iOS 原生应用发布之后,浏览信息是原来的两倍意味着什么?用户会在意你用 HTML 5 开发还是用的本地原生应用?绝大多数用户都不在乎这个,甚至都不知道,用户更关心的是「应用的速度」,App 是否足够快? 是否可以更流畅的阅读信息,没有人愿意在手机上等待某个应用慢吞吞的打开,就这么简单。

接下来面对 Facebook 的挑战是能否像在 Web 产品上进行的那些最佳实践那样也在移动产品上建立起更有效的研发机制,毕竟这是另外一个战场,一个互联网巨头在移动领域是否还是绝对的统治者? 没有人能知道。

事后诸葛亮一样来评价这个事情的对错本身并不重要,重要的是,我们是否可以从中学到某些教训?

EOF

HTML 5 来说,谈不上是什么「打击」,或许是好事情也说不定,让更多人认识 HTML 5 的优点和缺点,而不是一窝蜂的冲上去。

我在去年这个时间曾经说过这样一句话「我的两个固执的观点:1 HTML 5 不是移动开发的救星,至少现在不是;2 因为有 1 , 所以类似 PhoneGap 之类的解决方案还不靠谱,没有银弹。还需要再等 18 个月再看。」

现在看起来,还要再等 18 个月了。

本文首发: 福布斯中文网 (URL)。

技术布道的个人经验

我在做上一份工作的时候,一直试图做一个技术布道者(Evangelist,或传道士),最初的动机可能就是出于自己的个人兴趣, 乐于看到信息进行能够有效的传递并产生了价值。当然,因为某些原因,这样的事情在公司层面上无法得到正式支持,不过并不妨碍我利用个人时间做一些这方面的尝试,因为这事情坚持久了,多少也有了一点经验,有了一些感触。

在我看来,互联网行业先后有几个布道者值得效仿:前微软员工 Robert Scoble ,前 Yahoo! 员工 Jeremy Zawodny (现在在 Craigslist ) , Google 的 Matt Cutts ,Oracle 公司的 Tom Kyte,以及创新工场的蔡学镛。这些布道者,孜孜不倦地对外传递大公司的动态、新的技术趋势、新的产品信息以及他们自己对技术的思考感悟,有了他们,微软、雅虎、Google 不再那么神秘陌生。当然还有一些无法效仿的技术布道师,比如互联网之父 Vint Cerf 现在是 Google 的首席互联网传道士 ,只可高山仰止。

说起「布道」这个词,颇有一些宗教意味,的确,如果不是特别热爱或是信仰的话,是做不了技术布道的。有一句话叫「用影响影响影响」,说起来有点绕口,这句话也可以用来形容「技术布道」这个事儿。一个技术布道者,他自己多少要能够建立起足够的影响力,用这个影响力去影响一部分具备影响力的人,再促使这部分人自发的去影响更大的目标群体。好的效果是潜移默化的。

一个好的布道者不一定是一个好的演讲者,技术会议上能够滔滔不绝的演讲当然更好,但如果拙于口才也无碍,只要你是一个好的写作者就足够了。我在前面提到的几位值得效仿的技术布道师,都具备足够相当好的写作能力,我甚至分析研究过他们的写作方法和技巧,他们的博客现在也还有内容更新。我一向认为,文字的传播的持久性远比视频、语音的效果好很多。具备优秀的写作能力是成为一个优秀技术布道者的必备条件。

一个好的布道者要懂得利用新的传播媒介,他们一定是 Twitter 、微博的活跃用户,不懂得利用新传播媒介的人做不好这件事情。善于利用新媒介的一个额外好处是,获得相同的语境后更容易赢取社区用户的信任感,也能更好的和一部分具备影响力的受众互动。

技术布道不是一个「工作」,建议最好不要弄什么 KPI 之类的进行考核,因为效果实在无法量化。某些商业公司为了使自己的产品能被更多开发者接受,派一大堆人到各种会议上演讲,那不是布道,最多只能是一种营销方式而已。

技术布道需要坚持和耐心,如果只把他当成一项短期的任务是无法做好这件事情的。还不如去开一次媒体发布会。

作为技术布道者,你自己也会得到一些额外的「收益」,比如,更加有名气,当然是虚名,参加各种会议上有人叫你「老师」或者「专家」了;也有负面的影响,不排除也有人说你「忽悠」,所以,心理素质要再好一点才成。相信一件事情,你做的事情是有价值的。

EOF

多说一句,一个好的技术布道者一定是一个好的工程师,这一点,我自己就差太多了。

此文是《程序员》杂志用稿。

此文作者:, 位于 MyLife 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

技术转型的背后

某公司开发人员对该公司 DBA 不愿意从 Oracle 转到 MySQL 评价说「读点源代码会死吗?」

我看到该信息后评论到「能读源代码有个屁用?」 这有些偏激,读代码当然有用,不过读懂代码只是锦上添花的事儿,并不代表能管理好数据库。

就我对 DBA 群体的了解,不愿技术转型的原因典型可能在于:

1. 不少 DBA 的「不愿意」其实是对对行政意志的抗拒. 一个大型团队里面,的确要经常面对并且服从各种决策,不过,如果技术决策无视具体环境,违背了客观规律,完全是出于一两个人的好恶的话,那么对于整个团队来说,并不是好事情。理性的人一定会提前发出自己的质疑或是忧虑。

2. 也有是出于对 MySQL 的「不信任」。这几年 MySQL 有了很大进步,开源社区对 MySQL 的改进也相当好,但是,缺陷还是很明显的,比如,对于联机维护的支持能力至今还是不够的,尤其是对于需要支撑密集并发事务的网络应用来说,达不到工业强度。「可靠性」有的时候比「好用」或是「便宜」什么的更为重要。或许有人不信,拿 Facebook 来反驳,人家不是搞定了么?没错,Facebook 搞定了,但是记住,Facebook 的产品业务类型跟贵公司业务是一样的吗? 如果 DB 本身无能为力,你能从架构角度保证不影响业务呢? 另外,去看看 Google 为什么要开发 F1。

3. 对于某种「不确定」性的恐惧。对于一个自己暂时无法掌控的事物有排斥感,这也可能是人的某种自我保护的天性,超出了自己的「技术舒适区」,担心自己被淘汰或是价值被稀释。如果遇到持这种想法的人,倒是可以对他激励一下,「不都是数据库么?」小马过河,试试深浅再说。

4. 或许还有其他原因,不一一列举。

不过,不管什么原因,「读点源代码会死吗?」这种话都类似于体委主任要刘翔顺便去跑个百米比赛一样,不都是田径短跑么(原理都没变,不都是数据库么)?跑快点就行了嘛 … 读懂 MySQL 代码的人一堆一堆的,能给 MySQL 提交 Patch 的开发者估计在各大公司也不在少数,但是如果几十台上百台服务器崩溃掉,整个技术团队都看着你的时候,你能气定神闲的分析代码然后写个管用的补丁出来么? 这个时候,可没有人会提 「 MySQL 给公司解决了多少成本」,管理者会暂时忘了那事儿,他这个时候关心的是「可用性」了。

DBA 和做 Coding 是泾渭分明的两种思维模式,并无所谓高下之分,会写代码的没必要看不起做运维的,掌控数据的也别看不起做功能实现的,都是看人担柴不费力,如果你是真的去经历一番,就会得出另一种结论。

PS. 这个话题还会引出另外值得讨论的话题来,比如「技术决策的是与非」,今天日子特殊,等我有空再写一下。

EOF