posts - 319, comments - 22, trackbacks - 0, articles - 11
  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

为什么我要把公司做成扁平型

本文是从 Why I Run a Flat Company 这篇文章翻译而来。 
译者提示:本文中所提到的37signals是一家在西方很有知名度的公司,它是Ruby On Rails这个框架发祥地。

我一直在保持公司组织结构上层级体系的最小化。当有一个员工说出“晋升我吧”,我不得不重新评估公司的组织结构。

爬楼梯

几个月前,公司里发生了一些奇怪的事情:我们放弃了一个员工。这种事情在我创办的37signals这家芝加哥软件公司里并不常见。在过去的11年里,我们仅损失了5个人——其中还有个人在离开了7年后又回来了。

但这里真正奇怪的事情是这位员工和我一起决定在此时辞去的原因。问题出自志向抱负上——不是缺乏,而是过剩,我们无法接受。

她在我们的客户服务部已经做了差不多3年,工作一直很优秀。她聪明,主动积极,工作有效率,从未出过问题。现在,她希望获得管理职务、一个新的头衔,作为她这种表现的奖赏。这不是薪水待遇方面的问题。

你可能感到奇怪,这种事情怎么会成为了一个问题。毕竟,哪一个公司老板不想让自己的公司里多些希望能多承担更多工作的有积极性的员工呢?事实上,很多公司都经常的想办法多发明一些职位、职责、工作头衔,来留住他们的最有抱负的员工。

然而,在 37signals,我们对志向抱负有不同的立场。我们对那种、我认为是“垂直型”发展的志向报复并不多感兴趣—— 那是我们最常见的职业发展轨迹——一个员工从入职开始向上爬梯子,在多年的工作中从新员工爬上经理职务,爬到副总裁。相反,我们推崇“水平型”的志向发展方向——在这种情况下,当员工喜欢他们所做的工作时,我们会鼓励他深入研究,扩展他的知识面,让他在这方面越来越强。我们一直在努力招到一些渴望成为技术高手的人,也就是那些希望成为大师级设计师的设计人员,想精通编程技术而不是管理工作的开发人员。

相对于给予更高的管理职位作为奖赏——这样通常会把这些人从他们实际擅长的工作岗位上移走——我们奖赏跟他们的工作相关的东西。我们同时会提供高于市场水平的薪水和丰富的福利,包括夏天每周4天工作日,假期想休多少天都可以(当然,要有理由),在他们正在做的项目上给予他们充分的自主决策权。

这种策略我们使用了多年,效果很好。但最近,因为我们招入了更多的人,这种模式开始显现不适应的迹象。我们现在是26个人。就像很多企业家都知道的,一旦你的公司达到一定规模,以前你不会太注意的事情现在就变得不可忽视了。在我们公司现在这种情况里,诸如”部门”,“经理”,“头衔”的人力资源术语开始平凡的出现了。

除了要保持小规模,37signals一直在保持一个扁平型的组织结构。事实上,扁平化是我们的一个核心理念。我们有8个开发人员,但我们没有首席技术师。我们有5个设计人员,但我们没有创意总监。我们的客户支持团队里有5个人,但没有客户支持经理。而且因为我们没有市场部,我们没有首席营销主管。

即使我们规模扩大了,我们仍然维持着一个干瘪的组织结构。我们没有任何空间留给没有实际工作的人。在37signal的每个人几乎都跟我们产品的某些东西有直接的关系。从编写员编写和更新支持文档,到设计人员设计用户界面,到程序员给使用用户开发代码,他们都在尽自己的职责,我们没有一个拿着薪水只是去告诉别人去做什么的议院议员。

我们曾做过实验,把一部分人提升到管理层。在某些方面,这样做有好处;但另外一些方面,这样有问题。其中我们发现的一个问题就是,让团队自己管理自己通常比让团队受另外一个人管理要好。所以,当组织需要建设的时候,我们通常让他们自己去处理。

例如,当我们还是只有3个人在客户服务处的时候,我们招募了一个人去管理这个团队。这个人的职责是审查每个人的工作表现,注意他们的语气,确保我们的客户能得到迅速和正确的回复,并和我们的开发人员交流,让他们知道客户的需求,评估我们整个支持的执行效果。他也许可以投入到客服工作中,解决一些客户问题。但他的主要职责是退出前线、改进整个部门的工作。

效果不好。这并不是对某个经理的问责(他是个很棒的家伙,知道如何去管理一个部门,我们希望他能找到其它合适的工作)。关键问题不是谁在这个角色职位上;这个角色职位本身是没必要的。因为我们希望这个部门能够成长,所以我们就以为适当的调整现有组织机构是个好主意。毕竟,谁都知道,当你增加人手时,你就扩大了组织。

我们从这件事情中学的的教训是,增加一个专职经理、创造出上下级关系并不是建设你的组织的唯一途径。相反,我们决定让这个团队完全的自主管理自己。仍然会有一个团队领导,但这个角色是在整个团队人员中每周轮流轮换的。每周,新团队领导会勾勒出这周的议事日程,把问题和完成的任务写成报告,进入第一线来解决跟客户交流中遇到的各种问题。

我喜欢这种安排的一个原因是,它解决了常见的非常有害的管理者和劳动者之间的冲突,在这样的安排中,两种角色的人都能体验到对方角色的状况。你会发现公司中的很多冲突都是因为对相互的职务不了解产生的。因为这种每周的轮流管理,每个人都更能体谅其他人的处境。当你知道你很快就会被管理时,你就会更注意你的管理工作了。这让我想起一句最喜欢的名言、哲学家John Rawls说的:“最公平的规则是让那些不知道自己该有多大权利的人都同意的规则。(The fairest rules are those to which everyone would agree if they did not know how much power they would have.)”我们的客户支持工作上了一个新台阶,我们的客户比以前更满意了。我们对比了以前和现在的不同,我们知道现在是对的。

对客服服务团队的工作表现的观察,使我想到了横向激励而不是竖向激励会使每个人都受益。把有志向的人往上层推实际上是阻挡了团队里其他有能力的人。当有三、四个人都有管理能力(按传统的说法),如果只晋升其中的一位,团队气氛就会陷入困境。我们更喜欢一个所有人都能融洽相处的环境,让每个人都能有机会在横向上自豪的完全的发展。

最后我要说的是,当一个员工离开时大家都很不高兴。但作为一个公司老板,我必须去考虑公司的长远发展。只是因为他或她具有超出了现有的职位的能力就让其升上管理职位,这理由还不够充分。增设管理职位对于一个扁平型的公司来说实际是宣判了公司文化向等级制度的妥协。目前我们绝对没有这样的想法。我希望永远都不会有。

跟很多故事一样,我们的故事也有了一个完美的结局。我们的这位走掉的员工没有找到合适的工作——她创办了自己的公司。她管理整个公司,忙得不亦乐乎。我们还给她提了建议、帮助宣传她的新业务。对任何人来说这都是一个绝对正确的发展方向。

Jason-Fried
本文作者Jason Fried是37signals这个芝加哥软件公司的创始人之一,他也是《Rework》(中文版《重来》)这本书的合著者。

posted @ 2011-05-04 07:17 RTY 阅读(156) | 评论 (0)编辑 收藏

六种最具视觉效果的Android(安卓)手机浏览器

Android手机上有很多各种各样的应用软件,但想找到免费且好用的可不容易。这就是为什么今天我要向大家分享这六款最具视觉效果的android手机浏览器的原因。读一下每个浏览器的特点,看哪款最适合你。

Dolphin(海豚)浏览器HD版

Dolphin(海豚) HD浏览器是Android市场上最受欢迎和最强大的浏览器,它支持Android 2.0以上版本。除了一些诸如手势命令、多触点缩放、书签(同步谷歌书签)等基本功能外,Dolphin HD浏览器还支持很多像插件、HTML5、书签自定义排序、新颖的界面效果、更改下载目录等高级功能。

Opera移动浏览器

这是一个很快、很流畅的浏览器,能让你在移动设备上的上网冲浪具有前所未有的乐趣和效率。重新设计过的用户界面在手机中看起来更漂亮,使你的手机具有一个时髦的、很现代的显示外观。捏挤缩放和平滑的场景切换效果给你的互联网冲浪一个自然的、直观的感受。你还可以使用它把网页内容分享到其它的社交网站和网络上。Opera移动浏览器是连接WiFi网络和无线宽带的最佳浏览器。

Miren 浏览器

Miren浏览器通过对标签页浏览+智能全屏模式、顶部网站导航、智能提示等功能的支持,使你具有最直观的冲浪体验。这是一个支持Flash、多触点捏挤缩放功能的浏览器。它采用很方便的文件夹形式书签管理方式,让你更好的管理书签、通过SD导出、导入书签。

Skyfire浏览器

Skyfire浏览器能让你具有更丰富、更智能、更有趣的移动web冲浪体验。它还能让你的浏览活动更具社交化。你可以轻易的通过它来访问Facebook和Twitter上的新闻订阅,个人简介,朋友情况,收件箱,事件提醒和地点位置情况。它能通过你正在访问的网址来帮你发现朋友共享出来的流行网页内容,发现相关的信息。它能在你的视频和社交搜索结果是提供你更多的信息。

Opera Mini 浏览器

通过使用Opera服务器对网页进行压缩,Opera Mini浏览器不仅在加载网页速度上更快,而且能比普通浏览器节省九成的数据量。Opera Mini浏览器是在慢速的或按流量计费的网络上的最优选择。

Boat浏览器

Boat浏览器是一个快速的、简洁易用的Android浏览器。非常简洁和漂亮,能给你在Android上的web冲浪带来最优的用户体验。

posted @ 2011-05-04 07:14 RTY 阅读(314) | 评论 (0)编辑 收藏

你真正需要的代码测试覆盖率是多少?

本文是从 How much code coverage do you really need? 这篇文章翻译而来。

我写这篇文章的起因是由于看了@unclebobmartin在微博上的一些看起来言之凿凿的话语。给那些不认识Uncle Bob的人介绍一下——他是我们软件产业里最著名的一个专家,是《 Clean Code(代码整洁之道)》这本著作的作者,是敏捷宣言(Agile Manifesto)的签署人之一。在上世纪九十年代,他对文献最佳面向对象实践方法贡献了很大的力量。所以,当他说话时,我们一定要关注一下。

他给我们日常的TDD和单元测试制订了一个最高纲领。我们可以从他的微博里清楚的看到这点:

“两件事。可重复性和成本。跟自动化测试比起来,手工测试的成本高的可怕。”

“手工测试不是测试;那是在做实验。只要有人的因素牵涉其中,那结果就必然可疑。”

“你们告诉我的实际意思就是让我大开方便之门、不去测试某些程序。哼 …”

“代码覆盖率100%并不是成绩,那是最低要求。即使只写了一行代码,你也要测试它。”

他接着把软件测试跟在其它领域里常见的但被认为很关键的活动进行了比较:

“战地外科医生也许没有最够的时间做严格的消毒,但这带来的风险可能是死亡或高昂的治疗代价。”

“会计难道只会把80%的数据表做双份备份吗?”

“有多少回你们都看到了那些严重的宕机事故都是因为一些愚蠢的程序员以为那些愚蠢的代码不需要经过测试而导致的?“

他的所有这些观点都很有价值,但他只向我们展示了问题的一面。现实中并不是所有的应用都需要如此谨小慎微的测试。并不是所有的应用都跟战地手术或巨额资金核算那么重要。(更不要说在很多情况下的为”合理避税“而做的帐务:))。

一个更重要的原因是,100%的测试覆盖率并不能保证bug的不出现。就连Uncle Bob自己也承认:

”测试并不能杜绝bug。但测试能保证程序的行为是符合预期的。“

这很显然指的是:同一个程序员在程序里埋下的概念性或逻辑性错误,由他自己测是绝对测不出来的。

最终,所有的问题归结于ROI(投资收回率)和实用主义。有些应用比其它应用需要更多的测试。有些bug需要比其它bug投入更多的精力去修复。 究竟是否需要在自动化测试是投入更多的时间和财力,或多少覆盖率是合适的还是过分了,这都需要人的主观判断。

posted @ 2011-05-04 07:11 RTY 阅读(234) | 评论 (0)编辑 收藏

你去创业太老了

本文是从 But You're to Old to do a Startup 这篇文章翻译而来。

这么说,当你过了30岁,再来经营或创办一个企业就显的有点老了吗?超过30就意味着你不再有激情、驱动力和决心了吗?

papa-smurf

怎么算我也不老,我才34岁,但对于创业世界里的人来说,我似乎是就应该坐在某个企业的办公室里同跟我相仿年纪的人上班。年轻就容易创业吗?的确,当你年轻时,跌倒了更容易爬起来,失败了更容易重新再来。但不管怎么说,这也不能表明只有在年轻时才可以创业。

如今的年代是一个前所未有的创业好时机。你无需一个办公室,互联网可以让你和全世界所有的自由职业者联系起来,开源软件提供了你高质量的微软产品的替代物,大量的便宜的主机提供商提供你选择。有不计其数的阅读材料能教你如何起步入手;你甚至能在线填报申请来联合组成公司。

通过学习各种创业知识技巧,你可以最小化发展客户过程中的各种风险、以最小的成本生产出满意的产品。

但是,如果你也像我一样,有两个孩子,一笔抵押贷款,养一辆车,一笔助学贷款,各种日常消费,等等…!!我可不敢把话说死!但你要知道,这只是你前进道路上的障碍,你要解决它们,风险肯定会有。

最近我和Noah Kagan有一次谈话,关于我的家里个人劝我向另外一个方向发展。一个新成立的公司愿意提供我一个职位,做他们IT部门的负责人,薪水很高,公司运营的也不错。家里人说我应该有个稳定的收入,给家人留下更多一起相处的时间,我欠家人很多。但Noah给了我一些很好的思考,例如,两个方向,哪一个是我更喜欢的?如果选了一种不喜欢的工作会怎样?每天早上,当睁开眼后,我想做什么?想干什么?

做事必然会有风险。我可以接受这份工作,把无数的时间花在别人的产品上。或者我做我自己的公司,那是我的激情所在,是我每天醒来后就能享受的事情。没有完美的事情,在公司你可能被解雇、被炒,创业有可能会失败或成功。

热情和决心没有年龄的限制!

在创业公司使用Lean或敏捷开发方法,你可以快速的获得经验,快速的调整,降低风险。你的选择是什么?我是一个真正的信仰者,相信无论你想做什么,或正在做什么,你必须努力做到最好。不要让投资者们、其他企业家或任何其他人对你说你不行或你太老了。你的成功你自己决定。

posted @ 2011-05-04 07:09 RTY 阅读(169) | 评论 (0)编辑 收藏

     摘要: IonMonkey是Mozilla的新JavaScript JIT编译器,旨在为SpiderMonkey JavaScript引擎引入新的优化手段。 InfoQ 采访了IonMonkey首席开发者David Anderson,讨论了其进展,及它为使用SpiderMonkey引擎的产品如Firefox、Thunderbird、Adobe Acrobat和MongoDB所带来的性能进步。 ...  阅读全文

posted @ 2011-05-04 07:05 RTY 阅读(402) | 评论 (0)编辑 收藏

本文是从 S.O.L.I.D. Class Design Principles 这篇文章翻译而来。


本文是由敏捷宣言签署人之一、《 Clean Code(代码整洁之道)》一书的作者Robert C. Martin为他的《Applying Principles and Patterns》这本书搜集整理而来。

单一责任原则(SRP)

只有一个理由去修改一个类。例如,如果一个业务规则的改变会导致这个类的修改,那么,数据库、界面、报表格式或系统任何其它的部分的改变都不该迫使这个类做修改。

开发/关闭原则(OCP)

软件构成(类,模块,方法等)向扩展行为开放,向修改行为关闭。

Liskov替换原则(LSP)

子类必须能够用来当作基类使用。如果类A继承类B,任何能使用A的地方,B也同样可以使用。例如,是否还记得,正方形可以看作是矩形!当进行扩展 时:前提条件不许绕过,后置条件不能放宽限制,可见常量不能被修改(?)。常量:在扩展之前或之后,用户都需要依靠这个常量来传递信息。正确的使用set 形式的继承关系。不遵守set语义是非常危险的。归纳:使用超类的引用的任何上下文中也可以使用其子类的引用替代。这个原则极大的限制了在纯扩展(继承) 机制里可以做的事情。不遵守会带来风险。

接口分离原则(ISP)

一个类对另一个类的依赖应该限制在最小化的接口上。

反向依赖原则(DIP)

依赖抽象层(接口),而不是具体类。

其它重要原则

Demeter定律

也被称做封锁信息原则:只跟朋友交流

一个对象O的任何一个方法M只能调用下列类型的对象的方法:

  • 它自己
  • 它的参量
  • 它创建/实例化的对象
  • 它的直接组件对象

参考

好莱坞原则

不要调用我,我会调用你的。

不要自我重复(DRY)

去掉重复代码。

对接口编程,而不是对实现

反向依赖的另外一种说法。

你不需要它(YAGNI)

不要添加你“认为以后可能有用”的代码。只在“事到临头”时才添加代码。

简单化,傻瓜化(KISS)

让它能工作的最简单的方法是什么?

posted @ 2011-05-04 06:58 RTY 阅读(179) | 评论 (0)编辑 收藏

版权声明:http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html

如何为代码选择开源许可证,这是一个问题。

世界上的开源许可证,大概有上百种。很少有人搞得清楚它们的区别。即使在最流行的六种----GPLBSDMITMozillaApacheLGPL----之中做选择,也很复杂。

乌克兰程序员Paul Bagwell,画了一张分析图,说明应该怎么选择。这是我见过的最简单的讲解,只用两分钟,你就能搞清楚这六种许可证之间的最大区别。

下面是我制作的中文版,请点击看大图。

(完)

posted @ 2011-05-02 21:59 RTY 阅读(194) | 评论 (0)编辑 收藏

1、示例代码

1        QtCore.QTimer.singleShot(self.delaySpinBox.value() * 1000,
2                self.shootScreen)

2、关于QTimer.singleShot 的用法

void QTimer::singleShot ( int msec, QObject * receiver, const char * member ) [static]

This static function calls a slot after a given time interval.

It is very convenient to use this function because you do not need to bother with a timerEvent or create a local QTimer object.

Example:

 #include <QApplication>
#include <QTimer>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QTimer::singleShot(600000, &app, SLOT(quit()));
...
return app.exec();
}

This sample program automatically terminates after 10 minutes (600,000 milliseconds).

The receiver is the receiving object and the member is the slot. The time interval is msec milliseconds.

Note: This function is reentrant.

See also setSingleShot() and start().

posted @ 2011-05-01 13:21 RTY 阅读(2256) | 评论 (0)编辑 收藏

本文由程序猿What is the single most influential book every programmer should read?翻译而来。

国外知名网站stackoverflow上有一个问题调查: 哪本书是对程序员最有 影响、每个程序员都该阅读的书?

这个调查已历时两年,目前为止吸引 了153,432人访问,读者共推荐出了478本书(还在增加),其中最火的一本 书《Code Complete》被顶了1306次。

如果你是个程序猿,你一定有兴 趣看看这些书里你都看过几本,如果你一本没看过的话,我也不好说什么 ,也许你是个天才,但我相信大多数人都知道,你在学校里根本学不到什 么真正的工作中需要的知识,我们毕业后能帮助我们在公司中胜任工作的 老师就是这些优秀的书籍,一本好书可以改变一个人的一生。

下面是这个调查中排名靠前的书的一个简单的清单:

第一名:1306票《Code Complete (2nd Ed) by Steve McConnell》,中文版《代码大全(第二版)》,两届Software Jolt Award震撼大奖得主!

程序猿,程序员都该阅读的书

第二名:1161票 《The Pragmatic Programmer》,中文版《程序员修炼之道》

程序猿,程序员都该阅读的书

第三名:689票 《Structure and Interpretation of Computer Programs》,中文版《计算机程序的构造和解释》

程序猿,程序员都该阅读的书

第四名:557票 《The C Programming Language》,中文版《C程序设计语言》

程序猿,程序员都该阅读的书

第五名:472票 《Refactoring: Improving the Design of Existing Code》,中文版《重构:改善既有代码的设计》

程序猿,程序员都该阅读的书

第六名:472票 《Introduction to algorithms》,中文版《算法导论》

程序猿,程序员都该阅读的书

第七名:430票 《The Mythical Man-Month》,中文版《人月神话》

程序猿,程序员都该阅读的书

第八名:426票 《Design Patterns》,中文版《设计模式》

程序猿,程序员都该阅读的书

第九名:386票 《The Art of Computer Programming(First Volume Hardcover)》,中文版《计算机程序设计艺术第 (第一卷)》

程序猿,程序员都该阅读的书

第10名:353票 《Compilers: Principles, Techniques, and Tools 》,中文版《编译原理》

程序猿,程序员都该阅读的书

第11名:329票 《Head-First Design Patterns》,中文版《Head First 设计模式》

程序猿,程序员都该阅读的书

也许,这里的排名并不具有什么权威性,但绝对可以说都是好书!

这11本外还有很多书虽然票数不是那么多,但大家估计都耳熟能详,比如《Effective C++》(中文版《Effective C++:改善程序与设计的55个具体做法》),《Clean Code》(中文版《代码整洁之道》),《Effective Java》(中文版《Effective Java中文版(第2版)》等 。

记得有位先哲曾说过:

一种编程语言的重要性并不在于语言本身,而是在于这种语言来体现出来的编程思维模式。所以说,并不是你用到的书才去读,读书是一种习惯。

posted @ 2011-05-01 10:38 RTY 阅读(245) | 评论 (0)编辑 收藏

1. 示例代码

1        self.screenshotLabel.setPixmap(self.originalPixmap.scaled(
2                self.screenshotLabel.size(), QtCore.Qt.KeepAspectRatio,
3                QtCore.Qt.SmoothTransformation))

2. Label 的 setPixmap函数说明

pixmap : QPixmap

This property holds the label's pixmap.

If no pixmap has been set this will return 0.

Setting the pixmap clears any previous content. The buddy shortcut, if any, is disabled.

Access functions:

const QPixmap * pixmap () const
void setPixmap ( const QPixmap & )

3. 对QPixmap的scaled函数的解析

QPixmap QPixmap::scaled ( const QSize & size, Qt::AspectRatioMode aspectRatioMode = Qt::IgnoreAspectRatio, Qt::TransformationModetransformMode = Qt::FastTransformation ) const

Scales the pixmap to the given size, using the aspect ratio and transformation modes specified by aspectRatioMode and transformMode.

  • If aspectRatioMode is Qt::IgnoreAspectRatio, the pixmap is scaled to size.
  • If aspectRatioMode is Qt::KeepAspectRatio, the pixmap is scaled to a rectangle as large as possible inside size, preserving the aspect ratio.
  • If aspectRatioMode is Qt::KeepAspectRatioByExpanding, the pixmap is scaled to a rectangle as small as possible outside size, preserving the aspect ratio.

If the given size is empty, this function returns a null pixmap.

In some cases it can be more beneficial to draw the pixmap to a painter with a scale set rather than scaling the pixmap. This is the case when the painter is for instance based on OpenGL or when the scale factor changes rapidly.

See also isNull() and Pixmap Transformations.

QPixmap QPixmap::scaled ( int width, int height, Qt::AspectRatioMode aspectRatioMode = Qt::IgnoreAspectRatio, Qt::TransformationModetransformMode = Qt::FastTransformation ) const

This is an overloaded function.

Returns a copy of the pixmap scaled to a rectangle with the given width and height according to the given aspectRatioMode and transformMode.

If either the width or the height is zero or negative, this function returns a null pixmap.

posted @ 2011-04-29 23:02 RTY 阅读(713) | 评论 (0)编辑 收藏

仅列出标题
共31页: First 23 24 25 26 27 28 29 30 31