欢迎转载,请支持原创,保留原文链接:blog.ilibrary.me

合作

合作是指为了共同利益,每个人贡献自己的专业知识和劳动,创造社会价值的过程。 合作设计几大要素:

  1. 时间。时间才是最宝贵的,后面说的提升效率就是围绕节省时间这个核心。
  2. 专业知识。这是资本家出钱的前提,如果没有专业技能,只能卖苦力. 买苦力也分熟练工和新手,也是有专业和业余的区别。
  3. 角色分工. 角色分工不同是为了更好更高效地利用合作者的时间和专业知识创造最大价值.理论上给一个人足够多的时间,他可以学会所有的专业知识。
    1. 但是,时间不允许.
    2. 并且,即使他懂了所有专业知识和技能,他的精力也不允许他同时充当那么多角色。
  4. 钱, 或者报酬。劳动是为了收获,大部分人最直接的收获就是钱。还有的人收获的是成就感,也有人收获的是成长。 报酬的分配对激励合作者也非常重要,但不会是本文的重点.

为什么要合作

合作是为了做单个人做不了的事情,也是为了把每个个体产出最大化。

为什么要分工合作:

  1. 做大事。每个人的能力是有限的,专业知识也是有限的。合作可以把不同的专业的人整合起来,做一个人做不了的事情。这也是工程存在的意义。
    1. 工程是指以某组设想的目标为依据,应用有关的科学知识和技术手段,通过有组织的一群人将某个(或某些)现有实体(自然的或人造的)转化为具有预期使用价值的人造产品过程。
  2. 每个人做自己擅长的事情。分工越细,越专业,个体效率越高,单个流程出错的概率也越低。因为一个人在某个领域反复锻炼,必定会越来越精通,越来越熟练,踩的坑越多,出错的概率也会越少。分工以后合作就是必然的了。
  3. 每个人做自己喜欢的事情。做自己喜欢的事情得到的精神上的奖励比金钱奖励激励效果要好很多,也更容易带来幸福感。 4.

怎么提高合作效率

怎么提高合作效率。可以从个人角度来分析,也可以团队利益角度来分析。

相互帮助

合作第一要义是相互帮助,相互分享,相互提高。这样解释可能太抽象了。

举个软件开发的例子,从公共知识领域和私有领域来说明为何需要相互帮助.

一个软件开发项目会牵涉到很多公共知识领域,各种开源组件,各种服务,这些都需要大量的精力去学。

  1. 学习成本高。学那些公共知识的使用方法肯定是有成本的,有各种配置,会踩坑,会需要摸索最佳实践,还会需要根据自己的项目实际需求做一些调整。这些都会需要时间。
  2. 如果是涉及一些大型基础设施的搭建,那个学习成本就非常高了,因为大型的基础设施搭建会牵涉到很多各种概念和术语,让人抓不住重点,把时间浪费在不重要的东西上。如果有人踩过坑,几句话就可以指出方向,那么就可以节省大把的学习时间。
  3. 相互分享能显著节省大家的学习成本和时间,加快项目进度。

软件开发项目也牵涉到很多私有的代码。我相信大部分人都不愿意接受陌生的私有代码。原因在于一下几点:

  1. 代码没有说明文档。没有说明文档的情况下很难理解和掌握代码。
  2. 代码里面会有很多假设,但是往往没有注释说明。这种就是巨坑了。难度一点也不亚于女生让你猜她想要的是什么。
  3. 各种脏代码,冗余代码,淘汰的代码,这些都会消耗掉你大量的精力。
  4. 理解代码需要数据。那些数据很多时候只在实际生产中会有,开发环境下没有。没有具体的数据就很难理解业务代码。
  5. 在这些前提下,老人带新人,业务知识口口相传就非常重要了。

除了知识部分外,还有一些规则性的东西,流畅性的东西,摸索成本也非常高。比如怎么开通权限,去哪里构建服务,找谁申请资源等等,这些如果让每个人自己在内网寻找,那是非常耗时,对团队是不利的。对自己也不利,你不帮别人,反过来,你需要帮助的时候别人也不会帮你。

从上面三个方面来讲,相互之间的知识传授,团队内部的培训是非常有必要的。

把知识和经验作为自己的私有财产无可厚非,但是从个人发展角度来讲,能帮助别人的人更容易得到别人的帮助和认可,也更容易得到更多的发展空间。

任务明确

前面从节省个人时间成本的角度来说怎么提高合作效率。个人效率上去了,是不是就一切都OK了呢?

个人效率高是不够的。对于极个别特别突出的表现者,他们能自我驱动,给任务以后就可以自我推进快速完成。但是对于大部分合作者来说,必须明确任务范围.

如果没有明确的任务范围

  1. 没人做交叉的任务。有些交叉的任务,到底该谁做?都可以做的事情不明确指定人就没人会去做。
  2. 没人做本来该做的任务。不明确定义范围,那么有些隐式的需求,比如安全性的问题,性能的问题,兼容性的问题,可扩展性的问题,大部分会被忽略掉。为何?因为这些非功能性的问题范围非常广,一个功能随随便便可以延伸出十几个非功能性的需求,显然,这些非功能性的需求是没法都做的。如果只做一部分,那肯定还是会有问题。反正都是会错,大部分人就干脆选择不做了。
  3. 相互牵制。一些依赖性的活没人做,那大家就会干等着。
  4. 有的人会被累死。有的人干活很积极,别人不做的事情他们都会想办法帮忙解决掉。对于这种积极性,我们需要给予肯定和鼓励,同时也需要保护。一直压着他们超负荷运转,他们迟早有一天会扛不住。这种人一般经验非常丰富,我们需要保护他们,帮忙把他们的精力尽可能地腾出来去辅导别人,而不是把他们累死。辅导别人是做乘法,拼命给他们堆活是简单的加法。

需要明确责任范围和时间以及资源.

  1. 明确的责任范围确保每个人都能知道自己该干什么,
  2. 明确的时间能让每个人都有都清晰的目标,
  3. 明确的资源是任务快速推进的保障。

别指责

指责会带入坏情绪,对士气打击很大,也会破坏合作者之间的关系。 上级别指责下级,同级之间也别指责。

可能会有人说那要不要赏罚分明呢?需要的。这个最好交给制度去处理。把考核指标设立好,定期验收就行。或者交给团队外的人去处理,比如HR。或者需要提高的提高,需要提供帮助的提供帮助。指责没有帮助。

有领队

一定要有一个领队,他需要辅导别人,培训别人,协调资源, 攻坚,帮忙扫除障碍。

小公司的成败大部分情况下就看老板一个人, 小的团队看领队。领队能力要强,格局还得大。

领队还有一个很重要的角色,做决策,替成员背锅。如果成员出错了就得背锅,成员会自然而然的想要逃避所有的责任,不愿意干活,毕竟谁愿意背锅呢?领队可以通过决策来把责任摊自己头上,出了问题决策者来背锅。

放权和信任

  1. 一定要让成员放手去干。成员需要成就感,需要展示自己的聪明智慧。鼓励个人自由发挥,能提高个人的创造性。 如果真要约束,可以提前把规则定好,架构提前设计好,每个人都在规则允许范围内,架构框架里发挥就可以了。
  2. 另外,应该允许犯错。多做多错,不做不错,说的就是不允许犯错的情况下,大家都会选择不做。鼓励尝试,允许犯错,犯错以后及时修正,反倒对快速迭代演进会有很大帮助。

不阻碍别人, 不要让别人阻碍自己

  1. 别人有依赖的事情优先做。不要挡着别人的道。
  2. 流程性的工作优先做,因为这样往往有时间限制,容易过期,招致不必要的吗。
  3. 需要帮忙的地方第一时间说出来。哪怕后面发现自己就能解决也没有关系。整体效率最重要。流程性的问题,配置的问题,私有代码的问题尽量问别人。
  4. 有依赖别人的工作需要第一通知别人时间做.不要被别人给挡着了。

    规划和清单

    规划和清单与合作关系不大了,是从单一的视角来看怎么提高工作效率。

无论是个人还是团队,都需要有规划和清单。规划是一个整体的安排,能保证事情有序的发生。清单是执行层面的待办列表,保证做事不错不漏。

事情一件一件地做

如果能同时做很多事情当然很好。但是,不停地在不同事情间切换会极大地消耗精力,因为工作的中断成本比较高,做到一半停下来,等后面再捡起来的时候是需要成本去回顾问题,捋清思路的。最好的办法是事情一件一件地干掉,每件事情干掉打勾,再干下一件。

每件事都做了,每件事情都没有做好,极度消耗精力,也消耗意志,打击积极性和激情。所以要一件一件地做,不要同时做很多事情。

敢于说不,抛出风险,敢于求助

总会有做不完的事情,总会没法实现的需求。 这个时候需要敢于说不,把风险抛出来。不能把风险踹自己身上,误了大事。

不能为了图表现或者怕批评,把本来没法完成的事情承诺下来。事情做不完或者做不了是团队的风险,不应该个人承担。

  1. 把问题理清楚然后把风险抛出去,这是专业的表现。
  2. 把问题承揽下来,风险不上报,会误导团队的决策。最后烂了,影响的是团队。
  3. 理清楚待办的工作最重要。不理待办事项大家就看不清需要做的工作和潜在的风险。

搞不定的时候立马找别人帮忙,这是最明智的做法.

透明沟通,充分沟通

宁愿多说,丰富啰嗦,也不要漏说,少说。

  1. 很多拖延都是沟通不充分,不透明导致的。
    1. 被Block了不说,导致自己的任务没法按时交付
    2. 无法按时交付也不说,有风险也不提示,导致任务延期,耽误别人,耽误团队。
  2. 很多误解也是沟通不充分,不透明导致的。
    1. 沟通不充分导致重复劳动,相互覆盖。
    2. 沟通不充分导致需求理解错误,多做错做。

结对干活/Paired coding

结对编程绝对是最高效的,这一经验也适用于结对干活。

结对的时候相互监督,一起讨论,相互答疑解惑,相互分享经验,相互学习,效率翻倍。

拉一个会,一起解决一个问题,速度快,效率高。注意要拉小会,不要拉大会,拉大会浪费大家时间。

共同的愿景,喜欢所做的工作

从团队角度来讲,大家要有共同的愿景,朝着同一个目标前进。这样不需要时不时地停下来同步大家的状态。成员也不会迷茫。

从个人角度来讲,要从工作中找到能让自己开心的东西,喜欢上所做的工作。

  1. 有共同的愿景有助于大家力往一处使,推动产品快速发展迭代。
  2. 共同的愿景

每个人都能找到自己想要的东西

有自己想要的东西,心中有希望,个人才会有幸福感和充实感。

可以把下面几项做成问卷,问每一个成员优先级最高的3个地方。

  1. 有的人想要学习技术,个人成长。
  2. 有的人想要研究业务,了解行业。
  3. 有的人需要挑战,满足自己。
  4. 有的人想要做伟大的产品,成就自己
  5. 有的人想要升职。
  6. 有的人想要加薪。
  7. 有的人想要工作生活平衡,能工作的同时兼顾家人。
  8. 有的人想要一份工作,在工作中找到有规律的社交生活。
  9. 有的人是为了体验生活(富二代们).
  10. 其它.

    结尾

    本文没有讨论文化,也没有讨论冲突解决办法。只讨论了在简化的小技术团队内合作的问题。具体到大团队,跨团队的合作,需要考虑的点更多,甚至会牵扯到一些办公室政治问题,并且不可避免的需要向公司文化靠齐。

大团队所有的合作都应该放在具体的文化氛围下进行,

  1. 文化决定了具体的合作方式。
  2. 利益分配规则。
  3. 冲突解决方法。
  4. 小团队人少,大部分情况下没有明确的文化。
  5. 大公司的合作肯定是在文化约束下进行的。你肯定不能在一家外企里面强制大家天天加班,你也不可能在一家996公司里鼓励大家工作生活平衡。

本文讨论的内容仅限于技术团队的合作,不适用业务团队的合作。做业务的因为牵涉到太多的利益冲突,竞争大于合作,大部分时候在撕逼,不撕逼不正常。