创业团队成员的「挑战」以及「成长」的问题

回想从最初开始负责丁香园技术团队到现在,团队规模已经增加了几倍,有人离职,也有更多的人加入。团队一大,自然有些问题会浮现出来。比如最近在和团队同事聊天或是面试面谈的时候,经常会听到类似的话「觉得现在的工作没什么挑战」或是「感觉学不到东西」,以前偶尔听到团队同事这样的反馈,还是挺让我着急的,我第一直觉是很惭愧,公司或是团队给同事提供的资源和机会太少了,于是,不停的争取资源或是尽量改进,但是最后我逐渐发现,这样还是不能完全解决问题,这并非是问题的根源,因为一方面有人说没挑战 ,一方面是一堆老大难问题很久得不到解决。觉得「没挑战」和「没成长」其实是很多人会有的心态,尤其是刚参加工作没几年的容易形成这样习惯上的认知。

我以前写过一篇 工程师在创业团队的技术挑战 ,说了一下我对技术上的「挑战」的看法,现在趁着有点空闲,再谈谈谈创业团队中的成员的「挑战」以及「成长」的问题。{请注意,这只是一篇随笔,我无意去讨论什么管理之类的废话,也不奢望就这么几个字能解决所有问题,对少数人起到一个提醒的作用就足够了}

一般觉得工作没什么挑战的,原因可能无外乎几个: 要么认为自己的能力足够高了,不屑于再做「简单」的事情; 要么认为自己是在做「重复」的工作;要么,觉得没接触到新东西;也很有可能只是各种借口或是「心态」的体现。

实际上,任何团队中都没有「简单」的事情,只有做得好或是做不好的事情。什么是简单? 给产品写一段文字说明够简单么?写一封 EDM 够简单么? 如果仔细推敲的话,会看到绝大多数文案都是糟糕的一塌糊涂,那么为什么不用更高的标准要求以下自己呢?既然能力够高了,为什么你说的「简单」的事情还做不好呢?所谓眼高手低,不就是说这种情况么? 如果小事情做到比别人好,那么大一点的事情团队就会更加放心的给你去做。否则的话,换了是你,你也不会将重要的任务交给连小事情都做不好的人吧?

任何团队中也没有「重复」的事情。任何事情,如果不针对反馈做任何改进的话,做第二遍你就会觉得是重复;而如果每次都能根据反馈不停的修正,那么做成千上万次可能还会找到乐趣。比如说我们网站经常要给用户设计一些广告图片,有的同事说,总让我做广告图片,枯燥、乏味,我的设计能力如何得到提高? 的确,如果每次都用最低的标准要求自己,怎么提高呢?客户或是同事给你的反馈,比如,图片上的文字都是毛边的,无论怎么说你都无动于衷,那么怎么可能真的提高呢? 所以,面对「重复」的事情,必须不断的给自己设立新标准,然后努力去突破,重复的事情里面依然大有文章,想想如何提高质量,再想想如何提升效率。

至于说接触不到新技术,其实问一句话就好: 你业余时间为什么不学呢? 大部分回答是: 没时间。这是无解的问题。一般听到「没时间」,有时间整天逛淘宝难道没时间学习么? 其实潜台词都是「这是不重要的事情」,任何事情,你不投入比别人更多的精力,怎么做到比别人更好么? 正所谓,「以大多数人的努力程度之低,根本轮不到去拼天赋」,同样,不做好准备,也等不来机会。

至于心态,我引用丁香园 CEO 张进的一句话:两个都是新入职的同事,也都是第一份工作,交给他们差不多的事情做,一个想「他奶奶的,就这么点工资,让干这么多活?」,另一个则想「没想到新人都给这么多机会锻炼」,你说过几年谁的成就更大? 这或许可以回答某些人的疑问「为什么我和同学毕业的时候都差不多,怎么过几年不见,人家都做到某公司总监乃至副总了,我还是在不停的换工作?」,就是心态导致的差异。

有些人觉得创业团队或是小型公司里面,资源少,「学不到什么东西」,其实,是你没仔细去学习应该学的东西。前几天给几个好友的新创业项目提建议,我说你们某个地方做的不及格,他们说要我给讲讲,我说这个应该不用讲的,你们团队中的某某,以前看过我做同样的事情,按理说,他也能做一下的。遗憾的是,没去做,也做不来。为什么? 别人做他熟悉的那一点领域之外的事情,他是漠不关心的,意识不到学习更多东西是有价值的。有人说,问题就是机会,团队的问题,就是每个人的机会,谁能解决掉,就会给团队带来更大的价值,相应的,他也会得到更大的回报。而在创业团队里面,恰恰是需要解决问题的人,不欢迎那些不动脑筋的螺丝钉。创业团队中,可接触的问题不可谓不多,公司的方方面面都需要有人动手来做,如果平时多用点心思,学到的东西早晚在将来还会用到。很多人不都是有创业的想法么?但是你连基本的积累都不够,创业? 怕是要撞墙。

那么是不是在大公司里面才能让人得到锻炼呢? 曾经遇到过不少工程师当面告诉我,想去某某大型互联网公司去工作几年,提高一下技术,遗憾的是,几乎没看到一个人在几年后能力真的得到提升,有的甚至退步,为什么?一个很大的原因是,大公司里面多数的事情都已经固定下来了,而很多牛人之所以牛,是因为他们遇到公司从小到大的过程,在这个过程中他们得到了难得的成长机遇,不停的学习充实自己,解决各种问题,才成为牛人,牛人也多是苦日子熬过来的。等到天下皆定,哪还有那么多硬仗好打呢? 另外,「想锻炼技术」并不是一个很好的出发点,单纯的想锻炼技术实际上并不利于「解决问题」,培养能力和意识更为关键。

我在微博上调侃过:很多人都希望找到一个完美的公司,比如,办公室要无比舒适;用最好的设备;完备的培训机制,还别占用休息时间;弹性工作制;别他妈太累;也别让老子加班;公司前台要好看;没有刻板的工作流程;工作要有创造性不是重复劳动,别管我是否有创造性;队友不是猪而且都是天才,遇到困难他们就会出手解决;做的事必须是最潮的,但别管赚钱与否… 还有,最重要的,薪水要高。遗憾的是,这样的工作估计是做公务员也不一定完全具备,只会让自己更加痛苦,甚至增加无谓的抱怨。

提起抱怨来,也有必要说一下对队友的抱怨这个事情。曾经见过有人对一起合作项目同事的抱怨,比如设计师抱怨合作的产品经理有问题,总要不停的修改,时间长了,认为产品团队都很烂,经常打扰你,那么有没有想过,你是否可以给产品设计提出更好的建议呢? 甚至,有些产品设计你是否可以进行改进呢? 什么?「那不是我的工作!」 可是,为什么要给自己的能力设定一个边界? 这是多么可悲的事情,你完全可以无限制的突破边界,突破个人的局限。或许再过几年你会成为一个更好的产品设计师的啊。Zynga 的核心价值观有一条是「Level up」,不断升级,这恰恰是我们普遍缺少的心态。

的确,这是个浮躁的时代。大家容易听到各种各样的声音,每当心存困惑的时候不妨静下心来,加强对自身的认知。别幻想着走捷径,也尽量少去问别人如何成功,那些没有用,只要你别总在错误的路上越绕越远,将一些看似细微的事情做到更好,最后的成就依然惊人。

看清无处不在的「挑战」,让自己真正有所「成长」,毕竟,以后每个人都要承担更多的责任,只要你愿意。

EOF
最后补充一句话:「一个真正聪明的人,应该去发现别人话语中合理的部分,并且加以吸收利用,改正自己不正确的地方。而不是一发现别人言语中有漏洞或是有疑议就全盘否定。」

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

操作系统的迷思

你说这要一个多么不稳定的操作系统才会整天通知用户注意系统稳定性并且要花钱维稳呢? 百思不得其解…

一个操作系统越是封闭,越是想从最终用户身上压榨捞钱,就会常常的搞出很多消耗系统资源的垃圾软件或是病毒,系统也会变得极其不稳定,慢慢的就会被更加开放的开源操作系统所取代。

且说那个封闭的操作系统,其实也是当年直接从邻国搬来的代码,稍加修改就用上了,不但只能在少数硬件平台跑,还默认就会启动一个图形界面,面子倒是好看,但是效率太差,往往需要更好的硬件支撑,用户苦不堪言;而那个开放的系统,支持多个硬件平台,运行效率还极高,不在乎面子,更有里子。

封闭的操作系统有的时候要进行大规模重构,比如在上世纪六七十年代曾经遇到过惨痛失败;而开放性的操作系统因为基础架构合理,所需要的只是不停的改进就好。

继续说这个封闭的操作系统,一年一度的代码Review大会,今年要修改开发章程,引起关注的一个调整是第七十三条:对危险进程的处理方式:一经发现疑似危险进程,安全软件有权直接Kill掉不再通知父进程。令人遗憾的是,这个调整居然还被大会通过了。

开放的系统设计者的眼里:每个用户是平等的;而在封闭操作系统的设计者口中,当然也是所有用户都平等,只是有些用户比其他用户更加平等。

操作系统是一门复杂的课程,每一行代码都是不解之谜。

EOF

从 Solaris 到 illumos – 关于技术权力抗争、开源以及梦想的故事

今天看了现任 Joyent 工程副总裁 Bryan Cantrill 的演讲:Fork Yeah! The Rise and Development of illumos,讲述 illumos 项目的来龙去脉,披露了不少关于 Sun 、 Oracle 以及开源社区的信息,据说 Cantrill 在做这个演讲的时候,与会者很「动容」。而其中的陈年往事咀嚼起来很是值得思考。

首先说说这位 Bryan Cantrill ,「他曾荣登 MIT 《科技创业》35位35周岁以下顶尖技术专家榜,并被 InfoWorld 评为年度杰出创新家。在加盟 Joyent 团队之前,Cantrill 是Sun公司的杰出工程师。他在Sun公司花了十多年的时间研究了系统软件,包括从内核到浏览器客户端代码,以及和内核相关的多种组件。最有名的便是 Cantrill 联合设计并实现了DTrace。」(refer) 在 Oracle 收购 Sun 之后,Cantrill 于 2010 年 7 月离开的 Oracle,加入了 Joyent 。

在 Bryan Cantrill 的演讲中,他先是从个人的角度回顾了一下「历史」:从 SunOS 4.x 到 Solaris 的转换过程中,有很多优秀的工程师离开,导致这个问题的主要原因是引入了不成熟的 SCM 工具,Network Software Environment (NSE) — 可见,技术官僚的错误决定在哪里都是极有破坏性的。NSE 的糟糕引来了工程师的「逆袭」,Larry McVoy 干脆开发了一套 NSE 轻量级的变种,NSElite。通过 NSElite 以及后来的 Teamware , Roger Faulkner、Tim Marsland、Joe Kowalski 以及 Jeff Bonwick 等人领导的 Solaris 2.3 项目基本达到了还可以的并行开发的效率,不过到了 Solaris 2.4 就无能为力了,质量再次滑坡。

Solaris 2.5 的开发则是背水一战,只许成功,不许失败。这个时候,Sun 有了新的硬件 UltraSPARC-I 。为确保开发质量,工程师们进行了「接管」: Jeff Bonwick 担当起代码看门人的角色,坚持「if it’s broken, rip it out」的原则,确保了 Solaris 2.5 按时发布,并且确保了软件质量。经此一役,工程师们再也不愿意失去对操作系统开发上的控制。

到了 1990 年代中期,一个无法回避的论断是 Unix 必将死于 Windows NT 之手,而令人无法相信的是,Sun 居然是唯一一家意图对抗 Windows NT 的操作系统开发商。新一代「Bonwick Youth」的加入,天才们互相吸引,期待给操作系统带来革新,就像当年的 Xerox PARC 实验室那样。到了 2001 年年中,新的激进的开发开始了,这些新的操作系统功能包括:DTrace、ZFS、Zones、FMA、SMF 等。这些激动人心的特性并非由市场或是管理层驱动,而完全是工程师的想法。

ZFS,号称「终极文件系统」,首席设计师即为 Jeff Bonwick。

而这个时候,Linux 以及开源运动已经兴起,对 Sun 不可能没有冲击,内部也在反思。但是出于知识产权方面的限制,讨论了未有定论。2005 年,时任 CEO 的 Jonathan Schwartz 做出决定将操作系统开源,先是 Dtrace 开源,然后是 OpenSolaris ,时间是 2005 年 6 月。遗憾的是,有些小的但是至关重要的软件则无法开源(比如有些驱动程序含有第三方知识产权),为此 Sun 制定了 CDDL 许可协议,不过与 GPL 不兼容。

2007 年开始,Sun 决定创建一个全新的基于 OpenSolaris 的发布,名字仍然叫做 OpenSolaris,接下来的几年,Sun 与 OpenSolaris 管理委员会(OGB) 陷入了诸多摩擦,相互牵制。OpenSolaris 发展缓慢。

随着 2009 年 Oracle 宣布收购 Sun,到 2010 年收购完成收购。OpenSolaris 的命运已经很清楚了:Oracle 对此毫无兴趣。

Illumos Logo

2010 年的夏天,存储厂商 Nexenta 的 Garrett D’Amore 在 Rich Lowe、Jason King 等人的帮助下,发起了 illumos 项目, D’Amore 等人针对版权限制的软件,或是从头写代码,或是从 BSD 系统移植,2010 年 8 月 3 日,illumos 正式可用。「Illumos」这个词来自 Illuminare,也即拉丁语的 Illuminate,「照明、照亮」的意思,可谓深有用意。

illumos 项目的最终目标有两个:一是使用开源代码取代所有仍在 OpenSolaris 使用的专有代码,二是围绕之前的OpenSolaris 代码库建立一个独立的社区。严格来说,并非 OpenSolaris 的分支项目。

2010 年 8 月 13 日,星期五,Oracle 内部泄露出来的邮件写到「在企业版Solaris系统完整发布后,我们将会向得到许可的 CDDL 或其他开源授权发布更新。通过这种方式,技术创新将会首先出现在我们发布的版本中。我们将不再实时发布整个Solaris系统的源代码。」

Oracle 的对待 OpenSolaris 的冷漠乃至不作为导致了 Solaris 团队的大范围流失,比如前文提到的 Jeff Bonwick 也在 2010年 9 月 30号 离职。在不到 90 天内,DTrace 团队全部成员离开 Oracle,其他关键特性的开发人员亦纷纷离职。好消息是,这些离开的工程师全部加入了支持 illumos 项目的公司,比如 Nexenta、Joyent 、Delphix 等。关于 DTrace、ZFS 、Zones 等操作系统特性的创新将由 illumos 传承,但不会再次出现在 Solaris 上。illumos 软件库将成为记录操作系统技术危机的一个活标本。

从 Oracle 离开的 OpenSolaris 工程师们绝大多数活跃于 illumos 社区,给 ZFS 、DTrace、Zones 等带来了更多激动人心的特性。基于 illumos 的发布包括 OpenIndian、SmartOS、illumian 等,这些发布版面向不同用户群,互为补充,发展势头不错。

但是,发展中的 illumos 项目依然矛盾重重,去年 LWN 杂志的一篇题为 Illumos: the successor to the OpenSolaris community 的文章揭示了开源社区的一些明争暗斗。开发者 Stamos Tolias 抨击 illumos 项目的「思维狭隘,ZFS中心独裁以及大教堂式的开发模式」,并且企图另建分支。Illumos 的发展被认为不够开放,缺乏独立性,而 Oracle 的潜在诉讼也正在威胁 illumos 的命运。谁都知道 Oracle 公司打官司的「威力」。

也正是因为 illumos 项目由几家商业公司支持,暂时来看,怕是很难摆脱「大教堂」模式的开发弊病,而这引起了技术社区的批评。在这里,只能期待这些支持 illumos 项目的商业公司不要短视。祝愿 illumos 在将来能有更好的发展吧。

如诸君所见,illumos 项目寄托了一代技术精英的梦想。从 SunOS 到 Solaris ,从 OpenSolaris 再到 illumos ,期间发生的故事不知道有多少,关于 Sun 跌宕起伏的命运,关于技术权力抗争、开源以及梦想的故事,或许将来能有人详细如实的记录下来,一定非常有借鉴意义。

「Code over discussion; Innovation over democracy」
参考信息:

PS. 一时仓促,应有谬误,欢迎指出。

EOF

产品的最短路径

最近和同事以及一些业界朋友聊起用药助手这款应用的产品理念的时候,我常常会提及「产品的路径要短」这句话。其实我想表达什么意思呢?你的产品和用户要靠的非常近,尽量缩减中间环节,减少不可控环节的依赖。比如,通过一款产品解决人们看病的问题,的确是很多人的梦想,但是那需要太多支撑技术,遥不可及。远不如针对个别场景解决一个基本问题来得实际。

比较长的产品路径会有什么问题? 举个例子,假定你是一个创业者,从种种渠道的信息你断定健康信息管理市场潜力巨大。开发了一款小型电子设备,这个设备可以测量收集个人的健康数据信息(我们从各种报道中经常看见此类产品上市的消息),然后通过手机或者无线网络再传输到你的服务器上,然后… 听起来这是个很好的创意,健康数据多么值钱… 进行医疗分析或者辅助治疗,激动人心。且慢,这样的产品路径太长了。首先,你的设备制造就要考虑很多事情,设计、外包生产,然后,最起码做数据接口,各种设备得适配,再然后,要有渠道去推销给人们使用这个设备,用户毕竟不会飞来(能说服他们买单?),还需要有很好的售后支持…这其中任何一个环节对创业团队来说,要控制好,成本都太高了,而且,链条太长,也注定无法快起来。

所以,我建议创业团队做产品,路径必须要短。拥有简短路径的土鳖产品,也比华而不实的靠概念堆砌起来得产品更有价值。当然,凡事都有反例,但别用反例来反驳了,有些朋友会想起苹果公司,毕竟苹果的成功目前来看,还是不可复制的。这也是我不太看好一个电子商务巨头去进军手机市场的理由。

补充一点,做产品,也不要绕路绕的太远。比如,你发现有的用户在你的电子商务平台上进行欺诈,于是乎,投入大量人力物力研发反欺诈技术手段,过了一段时间,发现效果不显著,反欺诈工具无效? 提高技术研发力度?… 当然,也是治标不治本。正所谓,为了一根香肠,没必要去买一头猪或是养一头猪,更没必要去开养猪场。甚至,你需要的那根香肠可以用其他食品替代。

EOF
Updated: 就这个话题延伸一下,一个传统企业(比如某些医药企业)试图打造的自己某个产品品牌的在线社区也无疑是徒劳的,要么是拿钱打水飘,要么做成了「体外循环」,背离初衷。比较合适的方式?借助已经成熟的社区,事半功倍。毕竟,你只是想拉近和用户的距离,宣传品牌,培养忠诚度,但没必要总把用户拉来你家打牌吧?

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