Getting Real 第七章:组织

组织 第七章

一致性

拒绝分隔

很多公司将设计,开发,广告撰写,支持和营销分隔成不同的战斗单位。虽然专业化有它的好处,但是它创作的环境却让员工只看到自己的小世界而不是web应用的整个背景。

尽你所能的,整合你的团队,这样才能有一个健康的,反复的讨论贯穿整个流程。建立一个制约平衡的系统。不要让事情在翻译中迷失。让广告撰写者和设计者一起工作。支持的疑问一定要让开发者看到。

更好的情况是,雇用拥有多项天赋的人,他们可以在开发过程中担任不同的角色。最终的结果是一个更加协调的产品。

 


独处的时间

为了让事情做好,人们需要不被打扰的时间

37signals跨越4个城市和8个时区。从犹他州的普罗沃到代码的哥本哈根。我们五个人分隔了8个小时。这8个小时的距离的一个积极的副作用是独处的时间。

一天中只有四到五个小时我们都醒着并在一起工作。其他的时间,美国团队在睡觉而David,人在丹麦,在工作。剩下的时间,我们在工作而David在睡觉。这让我们一天中一半在一起而另一半独处。

猜猜在一天中哪一部分完成我们完成的工作最多?独处的那部分。这没有什么惊奇的。很多人喜欢的工作时间是清晨或者午夜 — 他们不会被打扰的时间。

如果你有很长时间没有被打扰,你就能渐入佳境。这个情境是你最有生产力的时间;这个时间内你不必在各种各样的任务中切换思维;这个时间你不会受到干扰,比如回答问题或者是查找东西,发送邮件或者应答即时通讯。独处的时区是产生真正进展的地方。

渐入佳境需要时间。这就是为什么干扰是你的敌人。这就像深度睡眠 — 你并不直接进入深度睡眠,你先进入浅睡眠,然后你会逐渐进入深度睡眠。任何干扰都会让你从头开始。深度睡眠是真正的睡眠魔法发生的地方;独处的时间是真正的开发魔法发生的地方。

在工作中建立一条规定:一天中一半的时间作为独处时间。从上午10点到下午两点,任何人都不可以和别人谈话(除了午餐时间)。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的,为了避免破坏生产力的干扰。

成功的独处时间意味着赶走交流痴迷。在独处时间中,放弃即时通讯,电话呼叫和会议。不要打开随时更新的email程序。只需闭上嘴去干活。(Just shut up and get to work.)

进入最佳状态

我们都知道知识工作者在稳定状态工作最出色,这种状态也被称作“渐入佳境”,他们全神贯注于工作,开足马力,忘了周围的环境。他们忘了时间的流逝, 在绝对的集中精力下产生了巨大的成果…那番在于这种情境太容易被破坏。噪声,电话呼叫,吃午餐,需要开车5分钟去星巴克喝咖啡还有合作者的打扰 — 特别是合作者的打扰 — 都破坏了这个情境。 如果你需要花一份钟处理合作者问问题的干扰,这足以破坏你的集中经历,那么你需要花费一个小时重新达到有效率,你的总生产力变得很糟糕。

—Joel Spolsky, 软件开发者, Fog Creek Software
(摘自 这些人从哪里得到他们(非原创的) 思想?)

 


会议有毒

不要会议

你真的需要会议吗?会议经常出现在概念不够清楚的时候。不要求助于会议,试着简化概念,于是你可以快速的讨论它,通过电子邮件,即时通讯或者Campfire。目标就是避免会议。你避免花费在会议上的每一分钟是你真正做事情的每一分钟。

对于生产力的毒性没有比会议更厉害的了。以下是几点原因:

  • 他们将工作日分解成小的,不连续的片段从而打乱了你的日常工作流程
  • 他们经常是关于词语或者抽象概念,并非真实的事物(比如代码片段或者一些接口设计)
  • 他们经常每分钟传达非常小的信息量
  • 他们通常包含至少一个笨蛋,轮到他时不可避免的通过无意义的话浪费大家的时间
  • 他们偏离主题比大雪中的芝加哥出租车还容易
  • 他们的议程经常非常模糊以致于没有人真正的明确他们的目的T
  • 他们经常需要精心的准备但是人们无论怎样罕能做到

在你确实地必须 开会(这必须是一个少见的事情)的时候 , 坚持这些简单的原则:

  • 设定一个30分钟的计时器。当它响的时候,会议结束。句号。
  • 邀请尽可能少的人。
  • 没有明确议程的时候不要开会。

少开会

有太多的会议了。放弃那些没有意义的和没有效果的会议。只有当需要讨论重要的商务议题的时候或者你需要建议,赞同或者一致意见的时候才召开会议。即便如此,不要不加选择的邀请人 — 不要不必要的浪费人们的时间。

—Lisa Haneberg, 作者 (摘自 不要让会议统治你!)

分解它

当子昂目增长的时候,增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。两个人只需要相互沟通;只有一条简单的交流途径。三个人有三条交流途径;4个人有6条。事实上,交流途径的增长是指数级的……很快,备忘录和会议汇占据整个工作时间。

解决方法是明显的:把团队分解成小的,自治的和独立的小单位以减少这些交流途径。

详细的,把程序也分解成更小的单位。既然问题的一大部分起源于相互的依赖(全局变量,函数间传送的数据,共享的硬件等等),找一个方法分割程序以消灭— 或者减少— 个体间的相互依赖。

The Ganssle Group (from Keep It Small)

 


寻找和庆祝小的胜利

每天发行点什么

软件开发中最重要的就是激励。激励是局部的 — 如果你没有被你正在做的事所激励, 机会就没有应有的那么好。 实际上,很有可能变得更糟糕。

冗长,滞后的发布周期是激励的杀手。 这使得庆祝活动之间间隔太长的时间。 另一方面, 可以庆祝的迅速胜利是极大的激励动因。 如果你让冗长的发布周期压碎迅速的胜利,就杀死了激励。 并且这样也会杀死你的产品。

所以, 如果你的发布周期是在一个月以内, 拿出每周一天(或者没2周拿出一天)对取得的小胜利进行庆祝。 并扪心自问: “我们可以在4个小时内发布些什么?” , 然后去实现它。 这可以是

  • 一个新的简单特性
  • 一个对现有特性的小改进
  • 为了减低支持负担,重写一下帮助信息
  • 去除那些并不需要的表格项

当你发现这些 4小时的迅速胜利时, 你将发现庆祝的理由。 这样鼓舞了士气, 增强了激励 并且 再次肯定了团队正在向着正确的方向前进。

0 Comments

Leave a reply

电子邮件地址不会被公开。 必填项已用*标注

*

联系我们

我们无法实时在线,但是您可以给我发个邮件,我们看到后会回复您

Sending
2016 京ICP备15001371号-2

Log in with your credentials

Forgot your details?