前言:
本文为 CODING 教你一步步从一个程序员变身成管理者系列文章的第三篇,文章内容来自 Unity 的一位研发总监,详细叙述了他的管理风格和处事态度,同时列举了不少扩展阅读材料来帮助读者更全面、更深刻地了解不一样的管理风格,解决职位转变带来的困惑。系列文章地址:git
《CODING 告诉你硅谷项目经理的项目管理之道
https://segmentfault.com/a/11...程序员《CODING 告诉你硅谷项目经理的项目管理之道(2)》
https://segmentfault.com/a/11...github原文地址:https://github.com/angrywease...
原文做者:Alan,现任 Unity 研发主管segmentfault
对于在我手下工做的人来讲,请把这份材料看成一份如何与我互动的说明手册。其实在差很少一个月的相处时间后,你都能或多或少地摸清楚门道,可是考虑到你刚刚加入到 Unity 这个你们庭,会有超多的事情须要学习和关注(遥想当年我刚刚加入的时候,一把辛酸泪),所以我整理了这份文档,但愿能帮你快速入门,了解咱们作事的风格。框架
对了,即便你已经在公司工做一段时间了,但对我还不是很了解,也欢迎仔细看看,对你们都好。运维
我认为在组内保持信息通畅是很是重要的。每一个组员应该每周与我预定一次约 30 分钟的 1 对 1 会议,建议提早选好时间(根据你的时区来),这样能够避免给其余会议或者工做带来冲突。工具
即便在我出差的时候,我也会按照预约的时间跟你聊聊,但若是咱们之间的时区相差太远致使没办法如约进行,咱们也能够找个其余时间经过 slack 或者视频的形式进行。由于做为一个管理人员,我须要了解并知足你的需求。个人工做中最重要的部分就是要助你成功,让你在 Unity 的时光有所收获,因此请善用这一点。学习
我作的管理人员的工做是去培养更多具备领导力的人。不管是在管理团队,仍是在解决客户问题,你都应该经过自身的领导力来推进团队作出改变,选用更好的工做,采用更高效的流程等等。在推进团队改进研发效率的这个过程当中,你会提升领导力并逐步改变对自身的定位。测试
我会尽全力帮助你成为更好的领导者,在咱们每周的 1 on 1 中,咱们也会常常讨论领导力相关的话题。我但愿你能带着问题来,把你最近在领导力方面的挑战拿出来,我会尽我所能地帮助你克服这些挑战。职业规划
只有极少数状况下我会用个人头衔来压人,我主要仍是以给你提供建议和解决你遇到的问题为主,从产品质量角度来讲,我绝对信任你和你的团队。
我在读质量控制方面的书的同时也看了大量的管理学和领导力方面的书籍。总的来讲,一部分观点仍是很不错的,另一些观点我以为不行,不过我如今已经有能力能取其糟糠去其糟粕,并逐步开始造成我本身的管理哲学。我也不清楚究竟是这些书中的理论在指导我,仍是由于我本身的观点获得了书中的确定从而带来了自信。
长话短说,有 4 个观点能比较完整的归纳个人管理准则。
1. 咱们以前是同盟关系
咱们之间的关系不仅仅只是管理和被管理这么简单,咱们的关系应该是互惠互利的同盟关系,并且目标一致,为对方创造价值和帮助对方成功。在你的工做为 Unity 创造更多价值的同时,我会帮助你在职业规划上和技能提高上带来更好的发展。
若是你想更深刻的了解这种同盟关系,能够看看 http://www.theallianceframewo..., LinkedIn 的创始人 Reid Hoffman 创立了这种新的管理人员/员工的关系框架,我认为其中有不少值得借鉴的价值观。
2. 指导和独立性
不管你是就坐在我身边仍是 1000 千米之外的办公室,你的成功都依赖于你独立解决问题的能力和主观能动性。我做为管理人员的工做仅仅是给你提供必要的框架内容(好比目标和角色之类的),而后我就会从你的眼前消失。在 Unity 工做的你们应该都能很好的跟人共事和解决问题,我只会在须要提供一点方向性指导,或者你有什么须要我帮忙解决的时候出现。固然,有些时候我也可能会插手一些具体事务,这并不表明你作错了什么,仅仅是我以为我看到了一些新的机会,这么作可能会帮助到你。
One Minute Manager (https://en.wikipedia.org/wiki... 囊括了不少相关的内容。
3. 我的提高是最重要的
我会使用两种理论模型来辅助组员的我的成长。第一个模型是是 Max Landsberg 模型(出自 Managing Humans:http://managinghumans.com/)。这个模型将工做的难度和员工对这份工做的接受度做为两个象限搭建一个四象限图。每一项工做都能归结到某一个象限上。个人目标是让你尽量作一些最想作同时难度要求又比较高的工做,这样你就能在为 Unity 提供最大价值的同时得到很高的我的成长。
另一个模型跟这个也很相似,我称之为 ACM(Ambitious, Comfortable, Mundane)模型,这个模型关注的重点在于工做的分配问题。每次你完成了一周的工做或者一次敏捷冲刺,能够停下来分析一下哪些工做是比较具备挑战性的(Ambitious)、哪些工做是作起来比较顺手的,惯例性的工做(Comfortable)、哪些工做可能比较无聊且对于你来讲过于简单(Mundane)。
咱们须要常常沟通,确保有足够多具备挑战性的工做来确保我的成长,若是有时候你以为工做上失去了挑战,就应该来跟我沟通,根据具体状况调整你的工做内容。同时咱们也但愿能尽可能减小对于你来讲简单的工做,术业有专攻,有些时候对于你来讲比较简单的工做可能对其余人来讲还挺具备挑战性的。
一个简单的实践方式就是把一个周期内的工做都罗列一遍,而后将每项工做分级。理想状态下,这个单子上应该有适量的具备挑战性的工做,让你保持不断学习的同时也不至于被搞的焦头烂额,还应该没有或者有一点儿无聊的工做,而后剩余的工做为常规性工做来保持平衡。若是你以为平衡被打破了,就应该找我来讨论一下,经过发现新的工做、改变现有工做内容的形式来恢复平衡。
4. 有效的反馈是关键
关于反馈,除了 Unity 自身的反馈规则外,我还会使用 Radical Candor (https://radicalcandor.com) 中提到的模型。
我会很频繁的给你关于工做和影响力方面的反馈。根据个人经验越及时的反馈价值越高。因此我会尽可能在本周的 1 on 1 会议中及时给出反馈。咱们会常常性地进行 3Q (https://3qcheckin.com/why-3q)方面的对话来确保及时的反馈。固然若是事情特别紧急我会直接跟你说,而不是等到 1 on 1 的时候。
固然,我也很欢迎关于个人反馈,我也但愿经过错误来学习和成长。
从技术人员到团队管理者的转型所带来的不只仅是身份上的变化,更多的是思惟方式和处事态度的转变。Alan 做为一个资深的技术总监,在他的分享中不单是本身的管理哲学和管理方式,同时也指明了一条通往管理者的道路,好比他提到的要从初期开始就进行领导力相关的培养、如何利用好身边的资源等等都在帮助但愿走上管理岗位的技术人员梳理脉络。同时他还给出了大量的延伸阅读材料,可供参考,能够说是诚意十足。
另外值得注意的一点是,Alan 对工做分配的要求很高,要减小甚至消灭无心义的重复劳动,这就须要高效的工具来实现——CODING 就能很好地解决这些问题,经过自动化的研发流程,减小人力的重复劳动。 CODING 提供持续集成到自动部署的全过程工具:自动构建、自动化测试、构建物管理、部署交付。支撑项目的快速迭代,保证软件稳定、持续构建和发布。能够无缝对接第三方运维管理工具,支持多种软件交付过程,实现 DevOps 持续交付全流程应用。
CODING 助力开发者轻松成为管理者。