专栏首页CODING DevOpsForter 的研发项目管理之道

Forter 的研发项目管理之道


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

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

原文地址:docs.google.com/document/d/1sx5ssYb_xMrmwPpyjD5xP7RvQ7cHweDYlRGn2SXztKw/edit# 原文作者:Oren Ellenbogen,Forter 研发 VP 译者注:Forter 是一家通过数据分析为金融、电商等行业提供反欺诈解决方案的供应商。

正文

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

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

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

我认为最重要的事

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

你的 take-away 信息:

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

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

你的 take-away 信息:

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

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

你的 take-away 信息:

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

我最不喜欢什么

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

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

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

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

  1. 做这件事能否更快地帮助我们发展。
  2. 做这件事能否让我们的客户更加信赖我们的产品。
  3. 做这件事能否帮助我们在市场上取得优势。
  4. 不要默认看上去很自信的人说的话就总是对的,要多和其他人接触来确认这些想法。

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

4. 没有主观能动性。

  1. 我认为工程师都应该具有一定的主观能动性去推动将自己的代码部署到生产环境上。没有部署到生产环境的代码是一种浪费。
  2. 在执行之前要确保所有前期准备工作的到位,提前跟相关人员约好会议时间,如果需要的话,提前取得各类许可等等。
  3. 不要指望别人来做这些工作,你应该是项目的掌舵人。

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

  1. 不能高效的沟通会严重影响组织规模的成长。
  2. 功能的负责人应该能精炼讨论内容并给出清晰的结论,这不是民主,负责人必须做决定,参与谈论的人只需要负责提供建议和权衡利弊。
  3. 更主动地去沟通信息,而不是到了节骨眼才去问。

个人管理风格

  • 在谈论中,我有时会表现的有些激动,可能会提高音量。我也挺讨厌这样的自己,但有时就是没法控制,我也在努力改进,如果你觉得有的时候我表现的有些过分,请告诉我,这不是我的本意。
  • 如果你在会议中表现出一副漠不关心甚至呆滞的样子,我会直接点名,因为我很讨厌这样的态度,当然如果有特殊情况(比如因为家庭原因这周你都没好好睡觉)请告诉我,避免误伤。
  • 我可能会时不时重复一些自己已经说过的话,有时你可能会觉得我很烦,我只是希望你接收到了正确/完整的信息而已。我也会经常在各种场合告诉你我是怎么想的,可能会有些重复,但至少我觉得我的想法都还是很清晰的。
  • 当你想找我聊聊的时候,请不要仅仅在邮件或者 slack 中问一句“在吗”,请附上你想讨论的议题,不然我会默认你接下来是要跟我讨论离职的问题。毕竟人在面对未知的时候都是往坏处想,我也不例外。
  • 对于组长们(研发经理,资深研发等)来说,我希望能主动告诉我你们是怎么想的,准备怎么改进或者执行而不是等我的指示,如果你有问题,来找我,我来帮你,但是归根结底你才是掌舵的人。
  • 没有什么事能比一场激烈的讨论更让我高兴的了,前提是要对事不对人,讨论完还是好同事。一场合格的辩论一定要以:“很高兴我们进行了一场有效的讨论,感谢各位的全力投入,分享你们的想法,现在就等【项目负责人】来做最终决定了“结尾。
  • 我喜欢有计划的工作,对项目有比较清晰的预估和时间规划,这样可以降低很多风险,当然如果因为各种各样的原因导致项目延期,我也不会拿这个来针对你,我会尽可能的帮助你来改善这种状况。
  • 我是破窗效应(en.wikipedia.org/wiki/Broken_windows_theory)的信奉者,在研发产品的时候我希望有整洁的记录,清晰的注释,详尽的规划。一旦事情开始混乱起来,就很难清晰的了解系统的健康度。
  • 最后,我喜欢写很多东西,我希望你也能开始写作 :D

译后记

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

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

本文分享自微信公众号 - 腾云 CODING(coding_net)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-05-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • CODING 告诉你如何建立一个 Scrum 团队

    Scrum 当中有三个角色:PO(product owner),敏捷教练(Scrum master)和开发团队。虽然这看起来很清晰,但如何处理现有职位的问题可能...

    CODING
  • 基于 CODING 轻松搞定敏捷开发

    敏捷研发是涉及整个软件工程的理念与实践,它的核心是迭代和增量式软件开发方法。开发者快速发布一个可运行但不完美的版本投入市场,在后续迭代中根据用户的反馈改进产品,...

    CODING
  • ​伪装的敏捷,我好累

    “敏捷已死”,人们一直这么说,但紧接着他们又说:“我们只是开个玩笑”。其实这些人真正想表达的是你实践敏捷的方式已经过时并且愚不可及,而“真正的”敏捷未死,只不过...

    CODING
  • python基础(01)

    今天开始更新python的基础知识,首先是为了能够帮助刚接触python的小白更好的学习python这门语言,其次是自己的一个知识巩固。注:我是认为你有C或者j...

    PM小王
  • Data Warehouse

    联机事务处理(OLTP, online transactional processing)系统:涵盖组织机构大部分的日常操作,purchasing, inven...

    李拜六不开鑫
  • 请求类型 GET 和 POST 的区别

    如果像 HTML 表单那样 POST 数据,要用 setRequestHeader() 来添加 HTTP 头,然后在 send() 方法中规定所要发送的数据

    Leophen
  • 单视图三维重建

    《Learning Shape Priors for Single-View 3D Completion and Reconstruction 》。再此分享给大...

    点云PCL博主
  • es6扩展运算符与可变参数

    var params2 = ['a', 'b', 5].concat(params1);

    用户3055976
  • Linux常用命令大全

    系统信息 arch 显示机器的处理器架构(1) uname -m 显示机器的处理器架构(2) uname -r 显示正在使用的内核版本 dmidecod...

    前朝楚水

扫码关注云+社区

领取腾讯云代金券