CODING 告诉你硅谷项目经理的项目管理之道

[CodingNET]

写在前面

优秀的项目管理者是怎么工作的，如何把一个研发团队的绩效激发到最大？
我们精心挑选了几篇硅谷科技公司研发管理者的 README 进行翻译。
README 主要用来向团队成员展示项目管理者的工作理念和工作方式，以便成员能够快速地融入到团队当中。
下文的 README 来自 Slack 的研发总监 Rand。
原文地址：http://randsinrepose.com/archives/how-to-rands/
原文作者：Michael Lopp (又名 Rands)，Slack 的研发总监
（译者注：Slack 是美国一款基于云端的团队协作工具。）

你好，欢迎加入团队。很高兴在 Slack 遇见你。

你至少需要一个稳定的季度把这个团队和业务弄清楚。我理解一位新人来到公司时急于表现自己的心情。但这是一个复杂的地方，充满了同样复杂的人。你可以慢慢来，先从与每个人见面开始，参加每次会议，记录会议内容并提出你碰到的问题——特别是那些看不懂的缩略语和表情符号。

我们之间的关系是首先需要定义的工作关系之一。以下是我的“用户指南”以及我的工作方式。它涵盖了我们一起工作的日常周里你能获得的内容、我喜欢的工作方式、我的北极星原则、以及我的个性特点。我希望通过这份文档为我们的工作关系快速预热。

日常工作周

除了高警戒状态（见下文）之外，我们每周至少需要 30 分钟来进行 1:1 （一对一）交谈，这个会议只讨论实质性内容。我为我们两人创建了一个私聊群组用来讨论 1:1 的主题，同时能够方便地查看我们讨论的历史记录。当我们想到某个主题时，可以直接发到这个群组中。

我们团队内部每周都有 60 分钟的碰头时间。与 1:1 不同的是，我们有一个涵盖整个团队议程主题的共享文档。与 1:1 类似的是，我们不讨论事务的状态，而是讨论影响整个团队的实质性问题。

你可以一天 24 小时发消息给我，我习惯立即回复消息。

如果我有旅行计划，我会提前通知你。尽管可能有时差，我们之前预定的所有会议仍然按时进行。

我在周末有时也会工作，但这只是我个人的选择，我不会强制要求你周末去上班。我有时也会懈怠，除非事情紧急，否则总是可以等到周一再处理。

我会使用年假，我建议你也应该使用。专注于私人事务时，我将不处理工作。

北极星原则

译者注：北极星原则指的是团队明确同一个方向前进，保持一致的愿景。

团队第一。 我相信快乐、透明、高效的团队会创造出色的产品，所以我的工作主要是不断优化团队。其他团队的管理者可能选择最大化商业、技术或任何其它重要方面。但我也认为思维多样性是高效团队的关键，而且所有观点都是相互关联的，所以我们需有这些想法不同的管理者，但我的个人观点还是高效团队第一。

人人皆可领导。 我的妻子经常提醒我：我讨厌职业生涯里头十年的会议。确实如此，我已经被糟糕的经理们举办的糟糕会议浪费了大量时间。作为一名工程师，即使也是一位经理，我仍然对经理持怀疑态度。虽然我认为管理者是大型组织的重要组成部分，但我不认为他们垄断了领导力。我努力在团队中建立机制和创造机会，以便非管理者也可以高效地领导团队。

系统地看待事物。 我习惯把将所有复杂的人员和事务整合一个到系统中，再用流程化的方式思考。我非常乐于了解这些系统和流程图是如何组合在一起的。当我发现系统中存在大大小小的低效率时，希望你能和我一起修复它们。

公平对待团队。 我相信大多数人都努力公平地对待他人，但无意识的偏见会导致他们的行为出现偏差。我也在努力解决偏见，因为我知道偏见会制造出不平等的现象。

心动不如于行动。 花长时间不停地讨论潜在方向当然是有价值的，但我相信行动是开始学习和取得进展的最佳途径。当然这也并不总是正确的，这种策略常常遭到一些喜欢辩论的人的反对。

不要忽视每次小改进。 我理解不断地改进小事情的复杂性，但我也相信质量保证是每个人的责任，并且待改进的错误真的是无处不在。

在事务开始前，我会预设所有参与者都是想要积极参与的，这对我的职业生涯有很大的帮助。

高度戒备状态。 当公司处于高度戒备状态时，团队的运作会变得和平时不太一样，我日常的许多实践和原则开始有了例外。进入高戒备状态通常是因为内外部出现了对我们公司的实质威胁。在抵御这些威胁期间，日常的团队管理、流程和产品原则都成为了次要事务。如果高警戒状态不是很明显，我会提醒大家我们处于这种状态，同时我会给出什么时候结束这个状态的预估。如果我一直处于这种状态，很可能是发生什么大事了。

反馈方式

我坚信，反馈是在团队中建立信任和尊重的核心。

Slack 每年会有两次的正式反馈周期。在我们第一次经历这个周期，我们会为你起草下一个审查期间的 OKR。这些不是产品或技术 OKR，这些都是你的职业成长 OKR。在我们开审查会议之前，我会把 OKR 以及团队整体反馈发送给你，这样你就可以提前了解情况。
译者注：OKR(Objectives and Key Results) 全称为“目标和关键成果”，是一套定义和跟踪目标及其完成情况的管理工具和方法：能够将目标管理自上而下 贯穿到基层。1999 年英特尔公司发明了这种方法，后来被 John Doerr 推广到甲骨文、谷歌、领英等高科技公司并逐步流传开来。

在我们第一次的面对面会议，除了确定下一周期的 OKR，我还会征求你对我平常工作的意见。在之后的审核周期又会有很大的不同，我将对照我们之前既定的 OKR 对你进行审核，如有必要我将引入新的 OKR，按照这种方式持续调整并重复。

审核期不是我们交换反馈的唯一时间点，这将会是我们平常 1:1 中反复出现的主题。我将在 1:1 里定期向你询问反馈。无论你多少次告诉我你没有反馈，我永远不会停止我的询问。

分歧就是反馈，我们越早学会如何有效地表达彼此的意见，我们就越早相互信任、相互尊重。简单的“同意”不会让想法变得更好。

会议约定

我每天会参加大量的会议，所以我将日程都共享给你们。如果你对日程上的会议有疑问可以随时与我沟通。如果是私密或保密的会议，你可能不会看到会议的相关内容，但这种会议是极少数的。

我认为一个标准会议需要包括具体议程、预期目标、适当数量的高效与会者，以及会议主持人。无论是参加会议还是主持会议，我都希望会议能够按时开始。如果我不清楚为什么要参加某个会议，我会要求会议发起人澄清需要我出席的原因。

如果你在会议开始前一个合理的时间给我会议材料，我会提前阅读，并准备好我的问题。如果我没有提前看会议材料，我会如实告诉你。

如果在计划时间点之前完成预期目标，我建议提前结束会议，把时间还给大家。如果很明确无法在规定的时间完成预期目标，我建议在规定时间之前停止会议，确定一个时间来讨论未完成的议题。

个人癖好与改进

我是一个内向的人，所以我非常社恐。对于处于我这种位置的人来说还挺奇怪的吧，在我看来三个人的会是完美的，三到八个人也还不错，但是八个以上的会你就会发现我表现得出奇的安静。但是也别因为我安静就认为我没上心。

当 1:1 话题都聊完了但还有些剩余时间的时候，我总是喜欢把我最近碰到的一些有趣的问题拿出来头脑风暴一下，虽然有些问题听上去光怪陆离地似乎跟现在的工作毫无关系，但这些的确都是我的一些想法，并可能会在未来有所实现。

当我给出的需求不太明确时，你应该让我澄清事情的重要性并给出更详细的说明。因为我可能还处在头脑风暴阶段，你的提问可以为双方都节省大量时间。

关于和我的对话方式我也想稍微提一下。当你需要让我做某事时，最好是通过询问的方式，我可以非常好地回答这类问题（比如：“ Rand，你能帮忙下吗？”）。但是我对命令式的话语会炸毛（比如：“ Rand，把这个做下。”）。我从小就这样，可能我需要看看心理医生。

我有时也表现得很夸张，但基本都是因为我对这个话题感到兴奋。我有时也说脏话，抱歉。

我喜欢新事物，但当我能够完整预见到事情未来的进展时，我可能会失去兴趣。抱歉，我在这方面会越来越好。

如果我在会议期间使用手机超过 30 秒，请做些什么来提醒我，因为我可能开始开小差了。

我讨厌人们将观点陈述为事实。

我也讨厌到处八卦的人。

最后

这份 README 是会实时更新的。目前可能不完整， 我会经常更新它，非常感谢你的反馈。

CODING 助力开发者轻松管理研发团队。