CODING 告诉你硅谷的研发项目管理之道系列（6）

写在前面

优秀的研发管理者是怎么工做的，如何更加高效地管理研发团队？这些一直是 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 中可能出现的一些主题。这是一个随时更新的文件，能够随时评论， 问问题等等。

你的工做理念

我在这里写了不少关于个人理念的文章， 但个人大量工做都在适应你的须要和理念， 我期待和你谈论它们。若是你感兴趣能够进一步阅读：
一、http://randsinrepose.com/welcome-to-rands-leadership-slack/
二、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）》