摘要：尝试写下你的第一个 README 文件

写在前面

优秀的研发管理者是怎么工作的，如何更加高效地管理研发团队？这些一直是 CODING关注的重要话题，我们不断地打磨 CODING 研发系统来让开发更简单。近期我们精心挑选了几篇硅谷科技公司研发管理者的 README 进行翻译。README 主要用来向团队成员展示项目管理者的工作理念和工作方式，以便成员能够快速地融入到团队当中。

原文地址：https://mattnewkirk.com/2017/09/20/share-your-manager-readme/
原文作者：Matt ，Etsy 研发经理
译者注：Etsy 是一个网络商店平台，以手工艺成品买卖为主要特色。

这是 README 翻译系列的最后一篇。Matt 受到了 Slack 公司 Roy 的启发，在此基础上，他融入了自己的内容：软件开发方面的价值观、重视工作和生活的平衡、开放的日程表、重视和其他团队的工作关系。

正文

从管理者角度来看，无论你是初来乍到还是有新鲜血液注入你的团队，入职这段时间都会有些艰难，同时这个时间段也是至关重要的。如何更好地度过入职阶段我认为有两个重点：
1. 分享期望
2. 建立信任

既来之则安之。知道你下一步需要做啥吗？如果你知道团队对你的期望，你就可以开始着手进行了。如果不知道，那你需要一定程度的信任来询问期望问题。

考虑到这一点，我写了一份文档和新下属们分享。我和加入团队的下属以及我加入的团队都分享过这份文档。无论哪种情况，我都描述了：我是个什么样的人、我希望如何与他们互动。我给每位新人都强调了这点：我鼓励讨论和反馈。如果我加入了一个新团队，我倾向于在第一次的 1:1 会议上提这一点然后再发送邮件给他们。如果他们是新员工，我会将其合并到一个更详细的入职文档，其中还包含了关键资源、要了解的专用名称、以及第一个月至一年的工作输出预期。

我从在 Slack 公司工作的 Roy Rapoport（ http://royrapoport.blogspot.com/ ）中发现了这招：我发现 README 是一个与新员工开始建立工作关系非常好的方式。
这是我的管理者自述文件。正如我鼓励我的下属做的，如果你有任何的问题或者反馈，请告诉我。

什么时候你可以和新下属开始建立信任关系？

作为你的 leader

我非常希望通过聊天来更系统地了解你，在此之前事先了解我的工作理念可能对你更有帮助。
我来这里是为了帮助你、支持你、为你的工作提供一个平台，并且为你和团队成员摇旗呐喊。我的工作范围看起来包罗万象，但其实我是为你而来的。

我的日程表里塞满了会议，安排和我一起的会议可能会让人望而却步。如果你在我的日程表上看到了空档，请见缝插针（你不需要先问），并且我会按时出现（除了临时会议，我的谷歌日程表是 99.9% 准确的）。如果发生了紧急事情你暂时没法和我见面，就给我发一个 Slack 消息或者短信，我会腾出其它时间。如果你需要重新安排会议，那也没关系。我尽力开放所有日程的修改权限（我用的是这个插件：https://chrome.google.com/webstore/detail/google-calendar-guests-mo/hjhicmeghjagaicbkmhmbbnibhbkcfdb ）。你可以按照默认值随时修改我们约定的会议日程，并将其移动到不与其它会议冲突的工作时间段内。

关于 DRI 模型

• 你来到这里是因为你的经验和技能，我不想推翻这两个。我是来帮助你成功的，但不是规定你应该如何行动。
• 如果我认为你判断错误，我肯定会尽量劝阻你，但和我意见不同并不表明你做错了什么。
• 你仍然需要得到队友的共识、赞同和投入。 

软件开发和进度

我坚信要让团队成员积极参与过程以及改变过程来达到我们的需求和目标。 我曾和敏捷团队以及非敏捷团队合作过、也以 scrum 以及非 scrum 方式工作过。以下是我的价值观：
* 我重视发生的事情、已经发生的事情以及将要发生的事情的透明度。
* 我重视速度以及主观努力，帮助团队快速前进 (例如，在新功能之前编写测试代码、重构遗留代码、结对编程以提高我们的代码质量和降低公车因子）。

译者注：公车因子（bus factor）描述的是因关键人物流失而产生的风险。

• 我重视学习，我知道在技术栈上进行培训可能并不是最快的产效途径。
• 我重视你的时间，不希望你做任何既对你没有益处也不符合政策法规的事情。
• ### 反馈是至关重要的

在建议匿名反馈的情况下，您可能会听到我依然建议你提供直接反馈，尽管匿名反馈总比不提供反馈要好。我致力于给你明确和及时的反馈，希望你对我也是这样。我认为持续的反馈需要三个属性: 
* 安全(你应该感到安全， 给予和接受坦诚的反馈) 
* 努力(你和我都不应该对反馈感到防御) 
* 效益(接受反馈应该产生影响) 

在这些方面如果我做得不好请告诉我，感激不尽。

工作和生活的平衡

大部分员工从早上八点（最早）工作到晚上六点（最晚），除非有紧急情况，否则我不希望在你的工作时间之外与你沟通。我尽量在非工作时间不回复邮件和 Slack 消息，并且在任何情况下也不指望你这样做，除非有紧急情况。

1:1 meeting

我认为 1:1 会议很重要，这些会议应该由你制定议程。你想谈论些啥呢？最近发生了什么？你在烦恼些什么？除非您真的想谈论项目状态更新， 否则我们不谈它们。对于面对面聊天， 我真的很喜欢一边步行一边进行 1:1 ；对于远程聊天，我很难集中注意力，除非我能通过视频看到你的脸。如果有什么事需要我的帮助，我会做， 但这是你的时间。长度、频率和媒介也由你决定， 但我希望我们每周至少有 30分钟， 最好每周有 60分钟，这个时间还可以更长。被具体议程驱动的聊天我更喜欢安排单独的会议（例如目标、查看项目反馈等）， 这样我们仍然有空间进行更及时的 1: 1 聊天。

工作关系

我会努力与你建立良好的工作关系， 我鼓励你与同行、商业伙伴（在办公室和你的团队中）以及其他办公室的团队建立良好的工作关系， 这样可以更好地了解我们团队事务的进展情况。我很乐意为您做介绍或提供在线建议。

回顾过去一周

我开始写每周博客总结（虽然我的更新是超级罕见）。它包含了我们的 1:1 中可能出现的一些主题。这是一个随时更新的文件，可以随时评论， 问问题等等。

你的工作理念

我在这里写了很多关于我的理念的文章， 但我的大量工作都在适应你的需要和理念， 我期待和你谈论它们。如果你感兴趣可以进一步阅读：
1、http://randsinrepose.com/welcome-to-rands-leadership-slack/
2、http://larahogan.me/blog/why-cant-they-just/

到这里 README 系列文章的翻译内容已经结束了。在看了 6 篇硅谷研发管理者的 README 文件后，你是否也考虑尝试写你的自述文件，好让你的新老板或者新下属更快地了解你的管理 风格。

写下你的第一个自述文件

自述文件写在哪儿呢？ CODING 提供了方便的 Wiki 和文件管理，试着在 CODING 项目当中写下你第一个的自述文件吧，或者你希望被更多的人看到，可以考虑通过 CODING Pages 传递你的个性、理念、工作方式。

自述文件写什么内容？ 几乎所有的管理者自述文件都包括以下方面：

• 这篇文档是什么？

  解释文档的背景和目的，这可以让双方更好地互相了解。

• 关于我以及我的工作

  你的工作职责是什么。
  你的个性是否有什么不一样的地方。
  如果你想了解团队的个人生活， 那就从分享你的个人生活开始。

• 个人原则/价值观

  您对人员及其意图的默认假设是什么？
  你在合作时采用什么样的心态，你希望其他人在团队合作中采用哪种心态？
  什么事情你不能忍受？

• 一对一

  你希望一对一是什么样的风格？ 大多数人遵循每周或者双周一次，一次 30 分钟的节奏，由员工控制议程。

• 反馈

  你想要哪种类型的反馈？
  如果人们对你直言不讳， 你觉得舒服吗？
  你喜欢如何提供反馈？
  你期望你的团队对反馈做出怎样的反应？

• 如何解读我的日程表

  几乎上面每个经理都希望下属知道团队是他们工作中最重要的部分，所以他们明确地这么说。 如果你需要谈话，请给他们留言， 他们会抽时间。

除了上述常见内容之外，还包括:

• 个人绩效标准

  如果员工问“我的工作表现目前处在什么水平？” 你将如何回应？ 大多数经理会通过标记 红/橙/绿的方式来进行回应。 虽然绿色和红色是明确的指标，橙色可以解释。 但这意味着什么，你打算让员工做出什么反应？

• D.R.I 原则

  不是每个人都信奉 D.R.I 原则，但如果你是，它可以是非常强大的。 首先，你需要设定员工负责任的期望。

CODING 基于硅谷先进方法与中国团队实践共同打造一站式开发体验，全面提升研发与管理效率。涵盖了软件开发从构想到交付的一切所需，使研发团队在云端高效协同，实践敏捷开发与 DevOps，提升软件交付质量与速度。

对往期 README 系列文章感兴趣可访问：
《CODING 告诉你硅谷的研发项目管理之道（5）》
《CODING 告诉你硅谷的研发项目管理之道（4）》