布客说

V1

2022/02/09阅读:58主题:默认主题

2021 年度总结(二)技术团队协作的原则及实践

团队是由一群追求一个或多个共同目标的人组成,通过一些规则约束在一起工作。想要让一个团队高效协作,核心原则必然是以人为本,让每个成员认同并遵从相同的协作原则,让个体与整体相互触进成长。

1)原则

Ownership & Leadership

每个人都应该有 Owner 或 Leader 的主人公意识, 如果看到团队或项目有问题的时候,不要等,请马上说出来,并尽量给出相应的建议或方案。

Initiative

每个人都必须是主动的,都需要自己发起要做的事,或是自己要认领要做的事,如果发现自己没有事情了, 需要学会主动发现问题,主动找到可以改进的地方,所有的创新都来源于此。

没有路要学会自己造路!

Objectives Oriented

每个人都是产品经理,也都是项目经理,每个人都必须把自己的工作和我们大的目标连接在一起,知道什么是重点,重点的东西就是两件事:1)从用户的角度出发;2)从产品的角度出发。

这意味着我们要随时观察整个产品的全貌,而不只是拘泥于自己负责的一块 。

Insists on High Standard

举法其上,得乎其中,举法其中,得乎其下,举法其下,法不得也。

我们要坚持用高的标准要求自己,对于高标准的目标不妥协,但是在实施路径和策略上可以妥协。

2)实践

Documentation Driven

面对面交谈、电话语音、微信、钉钉虽然是比较实时的反馈工具,但是只有文档是可以把重要信息给结构化的,而且写文档其实是比起前面的方式来说是更为深度的思考,因为会让你自己审视自己的想法。

所以,对于一些重要 “功能”、“流程”、“业务逻辑” 、“设计”、“问题”、以及“想法”,最好都以文档化的方式进行。

Design Review

对于一些重要的问题或是工作(每个人都要学会判断什么是关键问题和工作), 需要先把自己的想法 Share 出来,而不是先实现 。

一个好的 Design 文档需要包括如下项:

  • Background:交待这个事的背景、需求和要解决问题
  • Objectives:说明这个事的目标和意义
  • Alternative Solutions:给出多个解决方案,并能够进行 Pros/Cons 对比
    • Reference:方案需要有权威引用支持
    • Data:方案需要有相关数据数据支持
  • Conclusion:结论是什么

Simplification & Automation

简化和自动化是信息化工程所追求的两大目标,简化不是简陋,简化是对事物一种抽象和归纳能力,其能够提升软件的复用能力和扩展性,自动化是工程能力的重要体现,一方面,远程工作中自动化的能力可以让整个团队更高效地协作,另一方面,自动化是规模化的前提条件。

所以,我们要无时无刻地思考如何简化和自动化现有的事情。

Review & Re-factory

无论是代码还是工作都是需要反思和重构的。反思是进步的源泉,项目告一段落或出现问题时,都应该召集团队做集体反思,把好的东西坚持下去,把不好的东西及时淘汰。

Milestone Commitment

对于一个项目、每个人都需要有自己的 Milestone 计划, 这个计划最好是在 4 周以内,2 周内是最好的。

Evidence Driven

任何讨论和分析都要基于权威的证据、数据或是引用。在我们做设计的时候,或是有争论的时候,说服对方最好的方式就是拿出证据、数据或是权威引用。

比如:我的 XX 设计参考了 TCP 协议中的 XX 设计,我的 XX 观点是基于 XX 开源软件的实现……,如果争论不休就停止争论,然后各自收集和调查自己观点的佐证。

Effective Meeting

会议主要处理三件事:提出议案、发现问题、共识结论。

  • 会议不仅仅要有议题,最好还有议案
  • 会议期间不解决问题,只发现问题和跟踪问题
  • 会议必须要有共识和结论,如果不能达到共识和结论,那就当成问题处理,由问题的负责人跟进问题

关于周会或是临时性的团队会议(私下讨论不属于会议),会议组织者需要在事前收集会议议题,其中包括如下分类:

  • 项目类:需要事先有项目进度计划表(任何分项最好控制在 1-2 人周内)
  • 方案类:需要事先写好相关的方案和设计才能讨论(参看 Design Review 章节)
  • 问题类:需要事先写好相关的问题和解决提案(参看 Design Review 章节)
  • 决策类:需要事先写好整事的前因后果以及利弊分析
  • 信息类:需要事先写好相关的事宜说明

组织者需要在周五的时候发出会议议题收集,其中包括:

  • 自己知道的项目的进度跟进(需要相相关的项目负责人准备相关的项目计划)
  • 方案和问题类的需要各个项目负责人提出来,并有相关的设计文档可供 Review
  • 信息类和决策类的事宜需要提供详细的文档

其它负责人可以在会议上加入自己团队的东西,或是要求其他团队提供更多的信息。

Disagree and Commitment

在我们协作的时候,团队的成员都会有自己风格,经常会对同一个问题产生较大的争议(Disagree),我们鼓励有争议,但是是在团队的决议作出之前。

一旦团队形成决议,团队的成员就必须支持这个决议,并在这个方向上做出贡献。

但是关于决议的形成过程肯定充斥着各种的争论,对于这些争论,我们可以按照下面的 Guidline 来处理争议:

  • Owner 要负责对重大的讨论推进,尽快形成结论
  • 在决议过程中,要有纪要,并且要让整个团队知道,信息平等很重要
  • 不要妥协,坚持高的标准
    • 第一标准是工业标准
    • 第二标准是国外的大公司标准(如:Google、Github…)
    • 第三标准是国内的标准
  • Release 出去的东西,只要被用户用上了,要改就难了,所以要谨慎而果敢

分类:

其他

标签:

其他

作者介绍

布客说
V1