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

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

本篇文章来自于 Forter 的研发 VP：Oren Ellenbogen，同时他仍是 SoftwareLeadWeekly 的创始人和 Leading Snowflakes 的做者。本篇文章我的风格比较强烈，Oren 在他本身的 Readme 中展现了不少我的管理风格的喜爱和细节，同时也提供了大量的延伸阅读材料以供参考。

系列文章地址：
《CODING 告诉你硅谷的研发项目管理之道（4）》

原文地址：https://docs.google.com/document/d/1sx5ssYb_xMrmwPpyjD5xP7RvQ7cHweDYlRGn2SXztKw/edit#

原文做者：Oren Ellenbogen，Forter 研发 VP

译者注：Forter 是一家经过数据分析为金融、电商等行业提供反欺诈解决方案的供应商。

正文

先说说我本身，我做为 Forter 的技术 VP ，主要职责有如下几点：

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

还有一点很重要，就是我是为你服务的，若是你有任何须要均可以直接问我。同时要明确你不是为了我工做的，而是为 Forter，因此当你认为我在犯错误的时候，请直接跟我沟通，我也但愿像你同样获得成长。

我认为最重要的事

1.我是 1-(wo)man startups（https://venturehacks.com/arti...）理念的忠实拥护者，尤为在咱们如今的组织规模下（大概 25～30 位工程师）。虽然咱们中的一部分人在本身的领域很是突出，但为了保证组织的敏捷性和快速迭代，但愿每一个人都能把本身看成复合型人才看待。

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

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

你的 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...）的信奉者，在研发产品的时候我但愿有整洁的记录，清晰的注释，详尽的规划。一旦事情开始混乱起来，就很难清晰的了解系统的健康度。

• 最后，我喜欢写不少东西，我但愿你也能开始写做 :D

译后记

Oren 的 Readme 文档能够说是我的风格极强，把本身的管理风格表达的很是清晰，他还在后面加入了大量平常工做中的细节，好比每周 1 on 1 聊天的模版、如何跟他约时间、公司哪些内部资料须要仔细学习等等，因为太过于详细，这里就不作翻译，对细节感兴趣的同窗能够点击原文连接自行查看。

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

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