软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

10 | 如果你想技术转管理,先来试试管好一个项目

宝玉 2019-03-19
你好,我是宝玉,我今天与你分享的主题是:如果你想技术转管理,先来试试管好一个项目。
技术转管理,是很多技术人员的梦想,所以经常有人问我,怎么样才能转型管理?
项目管理,是最基础的管理,既要管理一个项目,又要协调整个团队一起,完成共同的目标。
我的管理转型就是从项目管理开始的,在从技术转型项目管理的过程中,让我从以前专注于局部技术实现,逐步转向关注项目整体;从个人的单打独斗,到借助整个团队的力量一起完成一个项目。
一直到后来做开发总监要去管理整个开发部门,发现还是一样绕不开要管理项目,只是从直接管项目变成了间接管项目而已。
所以我一般会建议:如果你想技术转管理,先试试管好一个项目。项目管理通常是技术人员转型管理的第一步,也是非常关键的一步!

技术人员转型管理的障碍是什么?

很多人认为技术人员是不适合做管理的,包括网上也有很多对程序员的刻板印象,比如说:极客、木纳、不善交际、头发少、穿格子衫……
而我了解的程序员却不是这样子的,他们都很聪明,学习能力强,而情商这些其实和其他职业群体是没有区别的。
那么为什么程序员会给人这种刻板印象呢?
一方面原因是这个群体勇于自黑,不介意这些印象;另一方面则是他们过于专注技术实现,沉浸于细节中,而忽视了其他事情。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(35)

  • Felix
    机缘巧合转管理已经快两年了,以下说说我的看法:

    1. 大局观,我十分赞同老师的观点,我领导经常耳濡目染地这么教我们,我也觉得这是我转管理后的最大收获,不能像以前看着自己的一亩三分地,站在全局考虑问题;正如张一鸣说的那句,“工作时不分哪些是我该做的,哪些是我不该做的”,这句话对我影响很大,做事不设边界,才能我有更大的成长,而这些对管理来说尤为如此

    2. 流程规范,接手管理后,发现虽然我们有一大堆流程规范的wiki,但很多形同虚设,我个人总结有以下几点问题:(1)不能很容易找到对应规范wiki (2)很多规范冗长复杂,不知所云 (3)流程规范太多,没时间看;
    于是我第一步就是整理杂草丛生的wiki,先保证目录清晰,让大家按目录写wiki,对号入座,查阅起来方便有条理,接下来挑出重点的流程规范进行了简化微调,每周会重点强调1-2个,在本周工作中重点关注,并适当提醒,渐渐大家一起走入流程的正规,并也体会到了按流程规范走所带来的便捷

    3. 管理该不该写代码,我觉的这事不能一棒子打死,我的观点有点像党的一句老话:从群众中来,到群众中去,在项目关键时刻负责一个小的Ticket,我觉的有以下几点好处:(1)因为平时的code review不可能面面俱到,这么做更加深入了解系统底层结构和代码,更加容易指导员工的技术细节问题 (2)让自己不是光说不练,纸上谈兵的领导,我觉得从我本身而言,可能中高层确实不必要,但我认为这对于一线管理还是很有必要的,能够树立威信,合作沟通更加顺畅

    4. 自己的管理风格,关于大棒还是胡萝卜,确实不同的公司不同的团队应该有不同的管理风格,这里没有对与错,但我认为对于扁平化的互联网公司,各种大牛,严厉的风格是我不提倡的,像老师说的激励帮助下属,团队氛围融洽,大家自驱地做事情我认为更可取

    作者回复: 👍这个补充留言很有料

    写不写代码其实也算管理风格的一部分,只要把握好度也很好的。

    2019-03-19
    18
  • 梦里是谁🌚
    来现在公司十个多月,技术人员从最初一个我,到十个人,都是我亲自面试进来的,跟作者一样我也是个温和的人,没有过多的批评,甚至有时帮他们完成任务。他们遇到问题时,我一般也是授人以渔,教会他们解决办法和思路,过完年公司融资不善,半个月前公司整体裁人,我们部门裁掉6人。上周五又继续裁掉3人,目前只剩下我自己。离别聚餐的时候每个人都表示舍不得这个团队,有人私下说如果遇到好公司有条件了想要我们都过去,还让我带领他们,也有人说如果公司好了希望再回来。感觉需要一段时间才能恢复自己的心情,虽然表面没有什么情绪,但是内心真的很。。。

    作者回复: 心情真的能理解!看远些,天下没有不散的筵席,以后还有一起合作的机会。目前大环境不好,个人能做的确实有限。

    一个管理者,给下属最好的礼物就是帮助他们成长,这也是他们即使离开还真心感激你的原因👍

    祝大家都好!

    ---
    追加回复:天大的王老师想联系您,这是他的邮箱:wangzan(at)tju.edu.cn,如果看到麻烦给他发个信。

    2019-03-24
    7
  • yasuoyuhao
    并不是你把上级的工作做了就能升职,而是你的下级都成长了,能替代你的位置了,你就可以升职了。
    讓我想到《火影忍者》有一句話一直記得。

    不是当上火影就能得到大家的认可,而是得到大家的认可才能当上火影。
    只有提升別人的價值,才能更加展現自己的價值。

    作者回复: 👍是的,在团队里面,能帮助提升其他人的价值的人价值最大

    2019-03-20
    7
  • kirogiyi
    我觉得管理者要做到的一点就是自律。首先管好自己,然后才能管好团队,做到言出必行、言而有信、正面积极,并给团队找准一个前进的方向,让所管理的团队能感受到工作的节奏和成长的空间,最大化的调动团队思想上和行动上的积极性。

    提到技术转向管理,应该最大限度的利用在舒适区擅长的技能来辅助学习区的成长,最终将学习区变成你的舒适区,摒弃原有的过时的舒适区。所以,除非情况万分危及,否则我们不能轻易动用舒适区这样的杀手锏,伤人伤己,害而无利。曾经看到过一句话:跑出离起点100米后感到口渴了,离起点50米处有水,你是回去拿水呢还是继续跑?我觉得长久的问题不能图一时痛快来解决。

    说白了,技术转向管理是眼界的变化,关注点的范围和程度的扩展,身体力行到运筹帷幄的升华,正所谓善战者无赫赫之功。

    作者回复: 谢谢补充,非常非常好👍

    2019-03-22
    3
  • 川杰
    老师,我的目标是成为架构师,想问的是,在您看来,架构师是否也属于管理者的范畴?
    因为他需要对产品的整个框架的负责,进而涉及到对每个人的代码的管理,必要时还要给带领团队成员去做重难点问题的攻坚。
    那么对于架构师而言,是更偏向技术还是管理呢?

    作者回复: 我觉得架构师和管理有相通的也有不同的,简单说一下我的观点:
    都需要大局观
    都需要好的沟通能力,让团队清晰的理解自己的意图
    都需要用好流程和工具
    都要善于“分而治之”,把复杂的问题拆分成小的具体的问题

    不同之处在于
    项目经理更多的是跟人打交道,对项目负责
    架构设计更多是专注技术,对架构负责

    两者互为补充,架构师有项目管理能力、项目经理有架构能力,都是非常好的

    2019-03-20
    3
  • alva_xu
    关于技术转管理,先从项目管理开始。这个观点我极其赞同。以下我谈谈自己的想法。
    1,老师举的是软件开发项目管理的例子,假定的项目经理是有开发技术的,所以需要克制自己不要有写代码的冲动,这一点我极其赞同。但假如项目经理以前并不是写代码的,这时候怎么办?我倒是觉得,应该学点代码,尝试写点代码,深入理解软件开发框架,培养点软件架构思想,才能充分理解开发人员的境况,更容易和自己团队甚至客户进行交流。同时无论你过去是开发大牛、还是应用架构师、领域专家、还是基础架构师,除非人员安排如此,否则,千万不要越俎代庖,把这些事情交给负责这些事情的人去做,你可以做的就是帮助指导,而且尽量要从方法上去指导,“授人以鱼不如授人以渔”。特别是一个比较固定的团队,培养一个人的成长比样样事必躬亲要好。
    2,管理牵涉到”人““工具””流程“三个部分的使用。项目经理首先需要学一些管理学的知识,如何激发”人“的潜力已完成目标是管理的最主要目的,所以一些管理理念比如MBO,管理方法(沟通技巧)都得学一点。对于”工具“,好的工具和差的工具效果不同,但更主要的是要用好工具,比如敏捷模式中,像Jira,或者VSTS等都是很好的管理工具,也就是老师讲的ticket工具,但怎么用好它,需要项目经理在团队内外进行培训推广,常抓不懈。还要考虑怎么把“流程”固化到工具中,那么项目管理就可以行云流水了,所谓子在川上曰,逝者如斯夫!
    3,当“人”“工具”“流程”都发挥了它们的作用的时候,项目经理就需要凭借自己的知识和经验、善于发现风险,管控风险。这时候,我觉得风险管理是项目经理最大的责任。特别是控制好“范围”(防止项目过程中范围扩大或者变小),“成本”和“时间”,以最终达到合理成本下按时交付完整的达到质量要求的项目交付物。
    以上几点,也是我从基础架构规划实施、然后做基础架构项目,现在管理软件开发项目好多年来的对于项目管理的一些经验,和大家共享,也请老师点评。

    作者回复: 你这不止是总结,很多内容补充的特别特别好👍

    非技术出身,反而是要学习技术,要信任技术

    流程工具和风险管理,后面两篇还会继续讲到,到时候还请继续点评讲解🤝

    2019-03-20
    3
  • 风翱
    团队的成功,才是你的成功.
    以前也是这个观点,但自身的例子,让我有些动摇。把下级培养起来了,结果不是升职,而是上级越来越把我边沿化,把我培养起来的人(在公开的场合直接宣布在我之上,私下只有我、上级和原来的下属,就说会列出权责范围,各自负责不同的地方,结果一个多月过去了,也没个下文)。对于这种情况,怎么调整自己呢?

    作者回复: 心情完全能理解,但建议还是看长远些。

    人生不只是一个下属不只是一个老板也不只是一个项目。

    以前我也纠结过这问题,现在不纠结了。因为我不止能培养好一个下属还能培养更多的下属,我能做好一个项目还能做好更多项目,我不需要靠一个老板的赏识与否来证明自己。

    2019-03-19
    3
  • hua168
    老师能否跟我们没有做过技术管理的人讲一下技术管理的工作内容、日常、关键性的会议、总结、文档等等…
    前不久,我前老总找我说可能打算开个公司做个电商网,我负责管理技术,其它他负责……
    我压力顿时巨大,不得不学开发(java编程),没做过技术管理,生怕不合格,我也矛盾中,如果我接了管不好,那脸可丢大了,也不知道管理日常是什么,要做那些工作…

    作者回复: 就像我文章中说的,管理呢,就是管人管事,你看很多老板也许不懂技术,但是能管得住懂技术的人。

    你这也一样,只要下面有懂技术的人,愿意帮你,那你就可以搞得定了。

    管理知识没有那么难,多学习理论知识,多像有经验的人请教,在实战中积累经验。

    2019-03-19
    3
  • dancer
    管人和管事,言简意赅,受教了! 但是对是否写代码,我个人的看法是,对于一个一线技术管理,比如不到十人技术团队的leader,我觉得时刻保持学习新技术,写写代码还是有必要的。好处一是做技术选型或者评审设计的时候,不会把团队带跑;好处二是做技术决策的时候,更有说服力。总儿言之,就是要有一定的技术领导力。

    作者回复: 你这个补充很好,我在文中说的有点绝对了,客观一点说法应该是尽可能保持一个合适的比例!

    但管理的团队越大,职责越多,那么要写的代码比例就要越少。

    2019-03-19
    3
  • aya
    请问宝玉老师,我在技术转型管理时遇到2个问题:
    1、本身项目很紧急,下面的人又并不积极对待,为了尽快完成只能自己写代码尽快上线,形成恶性循环。
    2、大领导对我技术不错的印象根深蒂固,总是直接指挥我们项目,为了进度,让我尽快开发,等上线后再让其他人人学习。
    我也比较矛盾

    作者回复: 也是几点建议:
    1. 招人、开人、培养人是持续要做的事情,必须要有人能替代你的那部分开发工作
    2. 需要利用项目管理知识去砍需求、去要资源、去争取时间
    3. 把写代码的时间和项目管理的时间要分开,例如上午专注项目管理事宜,下午专注于写代码,尽可能不要混一起
    4. 和领导也要多一对一沟通,让他知道你可以做好

    2019-03-19
    1
    3
  • 小老鼠
    毕竟管理职位少。如果在这家公司做了管理,脱离了技术,以后换工作会不会捡不起技术了?

    作者回复: 确实有这个问题,建议即使转管理岗位,也不要脱离一线技术,尤其是业余时间,应该保持对技术的学习和应用。

    比如我在做管理岗位时,回家后也会写一些代码,后来出国要转技术岗,很快能捡回来。

    2019-09-11
    2
  • javaadu
    1. 不同的岗位有不同的职责,基层管理者的职责并不是单纯的管理,要兼具技术深度、技术视野、项目管理、团队管理等技能。
    2. 关于“写不写代码”的讨论,作者说这句话的意思是,项目管理者要明白,写代码并不是万能药,不能过分得关注细节,要跳出来,看全局,要明白自己的职责——管理项目过程、控制风险,拿到结果。至于说是不是要写代码,那是另外一个问题,阿里现在已经取消了技术线的纯粹的管理岗位,就是希望技术线的基层领导者都不要把技术丢掉,要能跳出来看全局,同时也能带领团队打硬仗。
    3. 我有转型管理的计划,我希望自己能够实现从个人的成功到团队的成功,个人的成功,原因是:个人的成功,影响力有限,团队的成功才能完成更大的成就。我计划按照老师说的,从项目管理入手。遇到的困难就是自己的大局观不够,一冲动就喜欢自己上,这样的情况很不好:自己累的要死,还没什么成就感,然后团队其他成员也得不到充分的的锻炼。希望在后面的工作中,如果有项目管理的机会,自己能够改善自己的大局观。

    作者回复: 谢谢对于代码部分的补充,确实不是要丢掉技术,而是不要太过于技术👍

    大局观需要一点点培养,能意识到问题在哪是很重要的一步。

    祝转型顺利

    2019-03-24
    2
  • 舒偌一
    目标的一致性是遇到的一个困难,公司没有激励制度,导致项目经理和组员目标不一致,如何解决这个问题很挠头。

    作者回复: 目标一致性一个方法是多一对一沟通,你了解组员想法,组员知道你的期望
    另一个就是不必依赖于公司现有制度,自己创造激励制度,激励制度并不一定要花钱或者花很多钱,有时候正式的表扬比钱还有价值

    2019-03-21
    2
  • hua168
    老师,技术管理要购买管理相关的书吗?有什么书推荐一下?还是按照你的专栏跟着做理解思想,根据自己实际环境去调整就行了?
    我遇到好多个管理好的,每一个技术管理,管理风格都不一样,好像更多是结合自身,靠自己实践,自己去悟?

    作者回复: 我的专栏只是帮你入门,一定要多看书多补充理论知识!没有理论指导的实践就是摸着石头过河,有了理论指导才是有的放矢,能抓住重点!

    管理风格我有提到,结合自己性格特点比较好。

    自己实践中反复总结思考,多向老板请教,悟道肯定是少不了的。

    2019-03-20
    2
  • titan
    我曾在华为做了快七年的架构师,现在转管理也已经两年了,但是都是做的小公司的技术总监,我遇到的最大的问题,我感觉还是小公司如何进行技术管理的问题?我所在的公司,开发人员多的40、50人,少的10多个人,这个阶段,是用制度来进行管理,还是人来管理比较合适?当然,这个问题可能有点超出软件工程的范畴了。

    作者回复: 我觉得无论大小公司,一定都要多用合理制度流程,多用工具,摆脱对人的过度依赖,只是在设计流程规范时,要充分结合公司特点、项目特点。

    比如说小公司老板权力很大,有些流程普通员工有效,老板直接无视了,你还得做好隔离措施,让他不要破坏流程。

    比如说大公司很多工具、系统都是自建,小公司就不如买来的合算。

    大公司各种会议和文档相对多很多,小公司这方面就可以多精简,但必要的也不能少

    大公司用瀑布模型开发,一个项目几年耗得起,小公司还是敏捷一点,早点能看到产出更好

    将来有一天,小公司也会变成大公司,如果你之前没有做好制度建设,将来团队壮大,项目多了,你可能就会成为管理瓶颈。


    2019-03-20
    1
    2
  • hua168
    像我们运维这种,会shell、python/php一些简单的开发,懂点前端、后端、安全及网络,熟悉linux,小公司一般只有几个运维,多数是1-2个,如果升技术管理肯定要管理开发,像我们运维升技术管理和你讲的是不是一样的?

    作者回复: 技术包括运维技术的,其实是一样的。

    就像我做后端技术,要去管理前端技术,那其实本质上跟懂运维去管Java是一样的。

    开发的管理,如文中所说,你管好人,让团队为你所用,你管好事,让项目按质按量按时交付,那就是成功的管理。

    2019-03-19
    2
  • hua168
    技术管理是不是:
    1. 一定懂开发,参与过项目:这样你才知道用什么技术,开发某功能要花多久时间?

    2.当个项目经理:这样你有管理意识、沟通、任务分解及分配,懂得去全局看问题,更多的思考?

    3.思想和目光从深度向广度去转变:
    比如当前主流的技术及实现原理、架构师角度看问题、技术发展的趋势等,从局部观转到变成大局观

    如果能看懂代码,没做过项目管理/经理,能直接跳做技术管理吗?会不会变成外行人领导内行人?

    作者回复: 1. 需要懂一点开发,不需要特别深入,这样对方向和细节上会掌握的更好,最重要还是要有得力的技术干将
    2. 不仅是项目经理,所有管理岗都要求更多的全局思考
    3. 架构技术这些可选项,可以由架构师代劳

    项目经理对于代码要求没那么高,重要的是能找到技术好的人帮你。

    2019-03-19
    2
  • bearlu
    这篇文章,有把整个专栏串起来的作用。

    作者回复: 🤝

    2019-03-19
    2
  • zhxilin℃+
    老师关于舒适区的论述非常深刻!做技术管理前提是得有足够多的技术积累和能力,提高自己的技术水平、编程思想、解决问题的能力也是程序员的必经之路,绝不能片面地认为自己想成为技术管理就不必学习技术,这是个误区!稳扎稳打,步步为营,才能进步。

    作者回复: 👍嗯,懂技术对于做技术管理会有很多帮助。当然也不要对技术过于沉迷和过于自信 :)

    2019-03-19
    2
  • 冰封血影
    针对一些曾经贡献大的技术怎么管理呢?然而传统思维模式和产品迭代模式遗留的一些诟病,很难用新环境、新模式让他们去做改变。(这里并不是否定以前的模式)
    比如:对新推出的KPI这类漠不关心、对整个团队表现不出积极的面,反而带来了一些不好的点和面,但是做东西质量相比其他又高;这类怎么去处理和更好的提升整个团队的战斗力、协作力。

    作者回复: 几点建议:
    1. 多一对一沟通,了解他的诉求,让他了解你的期望
    2. 尝试安排一些有挑战的任务
    3. 充分发挥其优势
    4. “鲶鱼效应”,招聘技术相当的或者更高的,减少其不可替代性
    如果负面因素较多,可考虑:
    5. 隔离到某个项目中,避免对其他人造成负面效果
    6. 如果负面影响大于正向贡献,劝退也是个方案

    2019-03-19
    2
收起评论
35
返回
顶部