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

CODING 已经通过前四期文章，让大家逐步了解了一些硅谷优秀的项目管理者是如何工作、如何维持团队高效运作的。在过去的十几年中，中国的互联网行业发展过于迅猛，导致很多管理人员都是赶鸭子上架，商场如战场，不给你任何适应的时间，所以很多人还没有从技术人员的身份转变过来就开始带团队，在管理方式上难免会有所欠缺。这也是我们做这一系列文章的初衷，希望通过这些文章帮助研发管理者，自省或者回顾一下自己的管理思维，看看有没有哪些方向可以借鉴。同时也给将要成为管理者的技术人员一点预习材料，为日后踏上管理之路做一些准备。

本篇文章来自于 Forter 的研发 VP：Oren Ellenbogen，同时他还是 SoftwareLeadWeekly 的创始人和 Leading Snowflakes 的作者。本篇文章个人风格比较强烈，Oren 在他自己的 Readme 中展示了很多个人管理风格的喜好和细节，同时也提供了大量的延伸阅读材料以供参考。

正文

先说说我自己，我作为 Forter 的技术 VP ，主要职责有以下几点：

• 创造出”势必达成“的工作氛围（比如我们可以完成业务方面需要我们做的任何事），同时为股东和其他利益相关者提出相应的合理计划和所需要的支持。
• 通过一流的待遇以确保招到一流的人才。同时我们还希望能在相应的技术领域做出一些品牌影响力。不可否认，在公司成长过程中会有一部分人离去，但只要在问他们“你觉得整个团队的 EQ、IQ、好奇心和效率有没有随着时间越变越好”的时候，他们的回答是“妥妥的”，那就证明我们还是走在正确的道路上。
• 为组员定好合理清晰的框架，平衡公司需求和组员的个人职业发展。
• 通过不断迭代来优化我们所使用的 工具 和流程，确保组织和业务的可持续发展。
• 为组员提供指导，帮助组员提升领导力。

还有一点很重要，就是我是为你服务的，如果你有任何需要都可以直接问我。同时要明确你不是为了我工作的，而是为 Forter，所以当你认为我在犯错误的时候，请直接跟我沟通，我也希望像你一样得到成长。

我认为最重要的事

1.我是 1-(wo)man startups（ https://venturehacks.com/articles/1-wo-man-startups）理念的忠实拥护者，尤其在我们现在的组织规模下（大概 25～30 位工程师）。虽然我们中的一部分人在自己的领域非常突出，但为了保证组织的敏捷性和快速迭代，希望每个人都能把自己当作复合型人才看待。

你的 take-away 信息：
  1. 熟悉公司前进的方向并对如何达成目标所需要的技能有所了解，如果需要学习新的技术栈或者方法论，我会尽我所能帮助你。
  2. 你有权要求安排关于新技术的培训或者购入相关资料。
  3. 如果你更喜欢在某个领域钻研，那你也可以跟我聊，我们可以一起看看有没有这方面的机会，同时也权衡一下利弊。
  4. 我们鼓励组员接受新的挑战和职位。

2.当涉及研发如何帮助业务的时候，我的产品哲学是客户第一，产品第二，其他第三。虽然有点老生常谈，但是真正能够做到这个标准的组织还是少数，大部分人都会花非常多的时间在项目和产品层面，但是很少有人愿意真正花大量时间去了解：我们的产品是否真正意义上改善了客户的体验。我们的愿景是让我们的客户成功——请把这句话写下来摆在桌上或者记在脑中 :D。这份材料可以作为参考： https://www.useronboard.com/features-vs-benefits

你的 take-away 信息：
  1. 客户能否受益将是衡量你的产出的重要标准。
  2. 多花时间去和产品、市场和销售部门的同事聊聊。他们作为前台部门能最直接地了解客户的需求。在新项目开始前，找个机会请他们吃个饭，问问他们是如何判断客户需求和客户在意的点。
  3. 我坚信研发要能促进业务的发展，如果你发现有能够改善现在产品的机会，就应该扛起责任，推动各方来完善。

3.在快速发展的组织中，冲突是不可避免的。

你的 take-away 信息：
  1. 没有冲突的话，我们将缩在各自的舒适圈内，即使在需要的时候也没人敢提出反对意见。
  2. 我很欣赏资深工程师之间的那种信任。当你觉得有什么事在朝着不太对的方向发展时，要勇于提出异议。在提出意见的时候请尽量做到友善和建设性，但千万别憋着。
  3. 无论在何种情况下，先认清楚自己的身份：我是这个项目的负责人？还是顾问？还是路人。
  4. 在提出问题的时候，一定要就谁能做决定达成共识，然后确定如果这个问题超出权责范围的话应该去找谁沟通。确保每个问题能定论而不是不了了之。

我最不喜欢什么

毕竟我不是你的父母，不能一直庇护你。在知道了什么事情比较重要后，也应该了解一下如果表现出哪些行为且长时间没有改善的话会有可能会被开除。

1.利用公司和组织的资源来试图达成个人目的的人。

2.对手上的工作没有认知，不知道为什么要做这些工作。

为了忙而忙是一种效率低下的行为。我们希望能做正确的事情，所以必须要经常问自己一些问题：

a. 做这件事能否更快地帮助我们发展。

b. 做这件事能否让我们的客户更加信赖我们的产品。

c. 做这件事能否帮助我们在市场上取得优势。

d. 不要默认看上去很自信的人说的话就总是对的，要多和其他人接触来确认这些想法。

3.没有计划性。

当需求已经非常清晰的时候，我希望你对整个项目有很好地规划。比如这个功能可能要花 2-3 天，而这项任务可能只需要 2 个小时。之后再开始写代码。

4.没有主观能动性。

a. 我认为工程师都应该具有一定的主观能动性去推动将自己的代码部署到生产环境上。没有部署到生产环境的代码是一种浪费。

b. 在执行之前要确保所有前期准备工作的到位，提前跟相关人员约好会议时间，如果需要的话，提前取得各类许可等等。

c. 不要指望别人来做这些工作，你应该是项目的掌舵人。

5.不愿意花时间提升沟通技能。

a. 不能高效的沟通会严重影响组织规模的成长。

b. 功能的负责人应该能精炼讨论内容并给出清晰的结论，这不是民主，负责人必须做决定，参与谈论的人只需要负责提供建议和权衡利弊。

c. 更主动地去沟通信息，而不是到了节骨眼才去问。

个人管理风格

• 在谈论中，我有时会表现的有些激动，可能会提高音量。我也挺讨厌这样的自己，但有时就是没法控制，我也在努力改进，如果你觉得有的时候我表现的有些过分，请告诉我，这不是我的本意。
• 如果你在会议中表现出一副漠不关心甚至呆滞的样子，我会直接点名，因为我很讨厌这样的态度，当然如果有特殊情况（比如因为家庭原因这周你都没好好睡觉）请告诉我，避免误伤。
• 我可能会时不时重复一些自己已经说过的话，有时你可能会觉得我很烦，我只是希望你接收到了正确/完整的信息而已。我也会经常在各种场合告诉你我是怎么想的，可能会有些重复，但至少我觉得我的想法都还是很清晰的。
• 当你想找我聊聊的时候，请不要仅仅在邮件或者 slack 中问一句“在吗”，请附上你想讨论的议题，不然我会默认你接下来是要跟我讨论离职的问题。毕竟人在面对未知的时候都是往坏处想，我也不例外。

• 对于组长们（研发经理，资深研发等）来说，我希望能主动告诉我你们是怎么想的，准备怎么改进或者执行而不是等我的指示，如果你有问题，来找我，我来帮你，但是归根结底你才是掌舵的人。
• 没有什么事能比一场激烈的讨论更让我高兴的了，前提是要对事不对人，讨论完还是好同事。一场合格的辩论一定要以：“很高兴我们进行了一场有效的讨论，感谢各位的全力投入，分享你们的想法，现在就等【项目负责人】来做最终决定了“结尾。
• 我喜欢有计划的工作，对项目有比较清晰的预估和时间规划，这样可以降低很多风险，当然如果因为各种各样的原因导致项目延期，我也不会拿这个来针对你，我会尽可能的帮助你来改善这种状况。
• 我是破窗效应（ https://en.wikipedia.org/wiki/Broken_windows_theory）的信奉者，在研发产品的时候我希望有整洁的记录，清晰的注释，详尽的规划。一旦事情开始混乱起来，就很难清晰的了解系统的健康度 。

• 最后，我喜欢写很多东西，我希望你也能开始写作 :D

译后记

Oren 的 Readme 文档可以说是个人风格极强，把自己的管理风格表达的非常清晰，他还在后面加入了大量日常工作中的细节，比如每周 1 on 1 聊天的模版、如何跟他约时间、公司哪些内部资料需要仔细学习等等，由于太过于详细，这里就不做翻译，对细节感兴趣的同学可以点击原文链接自行查看。

同时可以看出 Oren 是一位对高效沟通和项目时间规划都非常在意的管理者，这其实也代表大多数研发管理者的需求，但是由于现阶段研发管理工具过于分散导致效率降低，也提高了统筹全局的难度。CODING 正是看准了这一研发管理痛点，推出了一站式的研发管理系统，覆盖软件研发从设想到交付的全流程。同时独有的研发大数据帮助管理者轻松掌握项目动态，提供研发效能，让企业研发管理真正“看得见，摸得着”。

CODING 助力开发者轻松成为管理者。