美文网首页
Getting Real 第七章

Getting Real 第七章

作者: Talen | 来源:发表于2015-03-06 21:19 被阅读24次

    第七章 组织

    第一节 团结

    拒绝分隔

    有太多的公司把设计、开发、文案、支持和市场分成不同的部门。虽然专业化有它的优点,但缺点是不同部门的员工只在乎他们自己的一亩三分地,而不是应用的整体。

    尽可能地把团队整合起来,保证项目开发进程中有一个健康的前后对话环境。设定一个相互制衡的系统。不要让事情迷失在信息传达过程中。让文案人员和设计师一起工作,确保开发人员能够看到支持查询。

    更好的情况是,雇佣具备多种才能的员工,那些能在开发过程中扮演不同的角色的人。这样就能产生一个更和谐的产品。

    第二节 独处时间

    人们需要不被打断的时间来完成工作

    37signals 的员工覆盖率四个城市和八个时区。从犹他州的普罗佛到丹麦的哥本哈根,我们五个人相隔八小时的时差。这八个小时的时差带来的一个积极副作用是,独处时间。

    我们每天只有 4-5 小时的时间一起工作。平时,美国团队休息的时候,丹麦团队在工作,其余的时间则相反。这确保了每天都有一半的独立工作时间。

    猜猜看我们的大部分工作是在哪个时间段完成的?是独处的时间。这并不奇怪。许多人都喜欢在清晨或深夜工作,在这些时间里,他们的工作不会被打扰。

    当你有大段的不被打扰的时间,你就能够进入状态。在这个状态里,你的效率是最高的。你的思维不用在各项任务之间跳转,你不会被打断思路来回答一些问题或发送邮件或者回复消息。独处的状态能够产生真正的进展。

    进入状态是需要时间的。这就是为何打断是你的大敌。这就像快速眼动睡眠(REM)——你不是直接进入 REM 睡眠状态,你得先睡着,然后才能进入 REM 状态。任何的打断都会让你从头开始。睡眠的奇迹都发生在 REM 阶段。软件开发的奇迹也同样发生在独处的状态中。

    为你的工作设定一条规则:每天拿出一半的时间独处。例如从早上 10 点到下午 2 点,没人可以找其他人谈话(除了午餐时间)。或者将每天的开始或末尾作为独处时间。只要确保这段时间是连续的,以此来避免严重影响效率的打断事件。

    一段成功的独处区间意味着免除了沟通的诱惑。在独处时间里,关闭即时通讯、电话、会议。避免所有需要马上回复的邮件。闭上嘴,开始工作。


    进入最佳状态

    我们知道,知识工作者的在进入“状态”的时候能获得最佳的效率,在这个状态下,他们能够全神贯注,完全不被周遭环境所影响。通过完全的专注,他们忘记了时间,创造出最棒的产品。问题是,这种状态很容易被打破。噪音、电话、去吃午饭、花 5 分钟去星巴克买咖啡,尤其是是被其他同事打断。如果一个同事打断你 1 分钟时间来询问一个问题,你需要至少半小时才能再次进入状态,这对你的整体效率是一个严重的影响。

    —— Joel Spolsky, 软件开发者, Fog Creek Software (from 人们的想法(非原创的)从何而来?

    第三节 会议是毒药

    不要开会

    你真的需要开会吗?开会的原因通常是一个概念不够清晰。应该尝试简化概念,使之能够通过邮件、即时通讯快速讨论,而不是寻求开会解决。我们的目标是避免会议。你从会议中节省出来的每一分钟都可以用来做一些真正有价值的事。

    没有什么事情比开会更影响工作效率了。以下是几个原因:

    • 他们将你的工作日分成琐碎而不连贯的碎块,破坏了自然的工作流程
    • 他们通常都是关于一些抽象的词汇和概念,而不是具体的事(例如一小段代码或者某些界面设计)
    • 每分钟所传递出的信息量极少
    • 总有一个白痴会在会议中说一些废话来浪费大家的时间
    • 他们比芝加哥暴雪天里的出租车更容易偏离目标
    • 总有一份大多数人都不知所云的会议议程
    • 会议需要充足的准备但几乎没人这么做

    当你必须要举行一个会议的时候(这种情况很少见),记住几个简单的规则:

    • 设定 30 分钟的计时器,时间一到,会议马上结束
    • 尽量减少与会人数
    • 没有清晰的议程,绝不开会

    少开会

    会议实在太多了。推迟那些没有意义的或者效率低下的会议。除非当你有一个重要的商业问题要讨论,而你需要获得输入、批准和同意,才有开会的必要。即使如此,也不要邀请每个人甚至是他们的兄弟——不要将人们的时间浪费在务必要的事情上。

    —— Lisa Haneberg, 作家(from 别被会议统治!


    把事情分解

    随着项目的增长,增加人手的边际效应递减。最有趣的一个原因是,沟通渠道数量的增加。两个人可以面对面交流;只有一条沟通渠道。三个人有三条沟通渠道; 4 个人有 6 条。实际上,链接的增长是指数级的...很快,备忘录和会议就会吞噬掉整个工作日。

    解决方案很简单:把团队分割成更小的,自主的独立单元,降低沟通链接。

    同样的,把程序切分成更小的单元。很大一部分问题都来源于依赖性(全局变量,函数间的数据传递,共享硬件等),找到一个分割方式,消除单元间的依赖性。

    ——* The Ganssle Group (from 保持微小)*

    第四节 寻找并庆祝小胜利

    在今天就发布一些东西

    软件开发中最重要的事就是动力。动力是局部的——如果你无法被你正在做的事情所激励,那很可能这件事就无法达到预期。事实上,很可能糟透了。

    冗长的发布周期是动力的天敌。那些你可以随时庆祝的快速成功是最好的动力来源。如果冗长的发布周期抵消了这种快速成功,你就杀死了动力。这也会杀死你的产品。

    所以,如果你正处于长达几个月的发布周期中,致力于从每一天每一周里寻找小小的胜利果实。问你自己 ”有什么是我们能够在 4 小时内完成并发布的?“ 然后照做,这些小事情可能是:

    • 一个简单的新功能
    • 一个现有功能的小改进
    • 重写某些帮助文档来降低支持负担
    • 移除某些你不需要的表单

    当你找到这些 4 小时的快速成功,你就找到了值得庆祝的事。这能建立士气,增加动力,并确信团队走在了正确的方向上。

    相关文章

      网友评论

          本文标题:Getting Real 第七章

          本文链接:https://www.haomeiwen.com/subject/ppqvxttx.html