跳转至

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

你好,我是宝玉,我今天与你分享的主题是:如果你想技术转管理,先来试试管好一个项目。

技术转管理,是很多技术人员的梦想,所以经常有人问我,怎么样才能转型管理?

项目管理,是最基础的管理,既要管理一个项目,又要协调整个团队一起,完成共同的目标。

我的管理转型就是从项目管理开始的,在从技术转型项目管理的过程中,让我从以前专注于局部技术实现,逐步转向关注项目整体;从个人的单打独斗,到借助整个团队的力量一起完成一个项目。

一直到后来做开发总监要去管理整个开发部门,发现还是一样绕不开要管理项目,只是从直接管项目变成了间接管项目而已。

所以我一般会建议:如果你想技术转管理,先试试管好一个项目。项目管理通常是技术人员转型管理的第一步,也是非常关键的一步!

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

很多人认为技术人员是不适合做管理的,包括网上也有很多对程序员的刻板印象,比如说:极客、木纳、不善交际、头发少、穿格子衫……

而我了解的程序员却不是这样子的,他们都很聪明,学习能力强,而情商这些其实和其他职业群体是没有区别的。

那么为什么程序员会给人这种刻板印象呢?

一方面原因是这个群体勇于自黑,不介意这些印象;另一方面则是他们过于专注技术实现,沉浸于细节中,而忽视了其他事情。

程序员总是想着如何技术实现、用什么语言框架、怎么提高效率……要钻研技术,这些是非常好的优点,但是要转管理,这反而会是一种障碍。

因为管理,最重要的一点就是大局观,要能从整个项目的角度,从整个团队的角度去思考,去确定方向,去发现问题,对问题及时解决及时调整。

但是当你把注意力都放在技术细节上,就容易忽视其他事情,例如和其他人之间的沟通、不关心当前项目进展。

就像有人说的:

关注细节的,是工程师;
关注过程的,是项目经理;
关注结果的,是老板。

所以,如果你要技术转管理,可以先从管好一个项目开始。这也是为什么我在专栏一开始,就建议你要逐步转变思维,从技术思维到工程思维,不要仅仅局限于自己负责的那一个小模块,而是要多从项目的整体去思考。

怎么样去管理一个软件项目?

软件项目管理涉及知识不少,既有传统的项目管理知识,又需要掌握软件工程的知识,所以很多人一谈到项目管理就觉得很难很复杂。

我在专栏中一直强调“道、术、器”,对于很多知识,如果我们能总结出其中的“道”,再去看很多问题,其实就没那么复杂了。

就软件项目管理来说,“道”就是管好人、管好事。如果从这两个维度去看如何管理项目,就会发现其实并不难,有很多“术”可以为我们所用。

怎样管好软件项目中的人?

软件项目管理的一个维度是管人。项目管理中的人,主要涉及两类:客户和项目成员。

1.管理好客户的预期

客户,就是会使用你软件产品的人,通常也是给你项目出钱的人。

对于客户的管理,就是对于客户期望值的管理,如果你项目的结果高于客户的期望,那么就可以说你的项目就是成功的,如果没有达到客户的期望,可能就是不成功的。

想要满足客户预期,通常来说,就是你能在项目的质量、范围、时间和成本上达到要求。

  • 质量达标:交付产品是高质量的,满足客户需求的。
  • 完整交付:按照约定的功能范围交付最终产品。
  • 按时交付:项目按照客户认可的进度完成。
  • 预算之内:在预算内完成项目。

这四个要素,并不是说必须都要满足,其实很多时候是可以协商的,重点是要达到一个平衡,怎么达到平衡?具体你可以参考《08 | 怎样平衡软件质量与时间成本范围的关系?》,我已经在这篇文章中进行了详细的解答。

2.用流程和规范让项目成员一起紧密协作

项目成员,也就是帮助你一起完成项目的人。

对于项目成员的管理,不需要过多依赖人的管理,否则项目经理就会成为项目管理的瓶颈。所以更多要落实到流程和工具上。

好的项目管理,不需要直接去管人,而是管理好流程规范;项目成员不需要按照项目经理的指令做事,而是遵循流程规范。

合适的项目管理工具,也可以简化流程,保障流程的执行,提高效率。

关于具体怎样制定流程规范,我会后续更新的文章《12 | 流程和规范:红绿灯不是约束,而是用来提高效率》中有更多介绍。

关于项目管理的工具,也会在《14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决》中有详细介绍。另外,你也可以先参考我在《06 | 大厂都是如何应用敏捷开发的?(上)》中提到的部分案例。

怎样管好软件项目中的事?

软件项目管理的另一个维度就是管事。软件项目中的事,是指要完成项目目标,在整个开发过程中所产生的一系列任务。对项目中事情的管理,本质上就是对软件开发过程的管理。

1.选择适合项目的开发模式
软件项目的过程管理,和其他工程项目完全不一样,有其独特性,好在软件工程对这些过程的开发模式都已经有了很好的总结,我们直接借用就可以了。

选择好开发模式,才好确定后续的一系列问题,例如流程规范、使用什么工具,如何制定项目计划等。

所以对软件项目过程的管理,首先就是要根据项目特点选取合适的开发模式,是敏捷开发还是瀑布模型或者瀑布模型的衍生模型?是一步到位还是逐步迭代?

对于开发模式的选择,可以参考《03 | 瀑布模型:像工厂流水线一样把软件开发分层化》《04 | 瀑布模型之外,还有哪些开发模型?》和《05 | 敏捷开发到底是想解决什么问题?》的内容。

当然,开发模式选好了后,还需要配套的流程规范,以及合适的工具,以保障开发模式的执行。

2.制定好项目计划

凡事预则立不预则废,在选择好开发模式后,紧接着就是要做好项目计划,有了项目计划,才能有计划有目的地去推动项目进展,出现问题也能及时发现、及时调整。

对于如何制定计划,我将在下一篇更新的文章《11 | 项目计划:代码未动,计划先行》中进行详细讲解。

3.对计划进行跟踪和控制,同时做好风险管理

计划制定后,并不是说事情就会完全按照我们设想的进行,实际执行难免会和计划有些出入,所以还需要对计划进行跟踪和控制。当项目的推进过程中,如果计划有出入时,需要分析原因,对计划做出调整。

同时,也不能盲目乐观,对于项目过程中可能存在的风险要进行识别,做好B计划,这样一旦风险发生变成问题,可以及时应对,减少风险导致的损失。有关风险管理的内容,可以参考《15 | 风险管理:不能盲目乐观,凡事都应该有B计划》。

管好人、管好事,你就能管好软件项目。除了上面介绍的一些项目管理知识,涉及软件项目管理的知识内容还有很多。这里并不是说其他知识内容不重要,而是在刚开始的时候,先把这些事情做好,可以保证项目管理不会出现大的偏差,然后逐步拓展到其他知识领域。

在这里,我把前面说的内容做了个简单的思维导图,希望可以对你的项目管理转型起到一定的帮助作用。

技术转管理的一些经验教训分享

技术转管理的路上肯定不会是一帆风顺的,要自己踩过很多坑才能成长,我这里也给你分享一点经验教训,希望能帮助你少走一点弯路。

  • 控制你想写代码的冲动

我给每一个刚从技术转型管理的同学的第一个建议都是一样的,那就是:“不要写代码,不要写代码,不要写代码,控制你想自己动手写代码的冲动。”

前面我说过技术人员转型管理的最大障碍是什么,那就是过于关注技术,而忽略了其他事情。从技术转型管理,是个巨大的转变,这种思维的转变是很难一蹴而就的。

对于程序员来说,写代码是自己的“舒适区”,而管理则是“学习区”或“恐慌区”,在转型的过程中,特别容易回到舒适区。

比如你看某个接手你的程序员代码写的实在是不够好,那是你最熟悉的,你只要一小时就写完了,而他要一整天的时间,还没有你写的质量好,你会很有冲动去帮他完成。

比如说在项目进度吃紧的时候,你可能第一想法就是自己去写代码帮助团队赶上进度。

但是,你要知道,当你转型管理后,你的主要职责就是管理,而不是写程序。如果你还是把大部分时间用在写程序上,那么你就很容易忽略项目中的问题。比如没有去关注项目的进展、目前项目的瓶颈、和客户以及其他项目组之间的沟通协调等。

这就是为什么你第一步是要控制自己写代码的冲动。作为一个项目管理者,你的第一要务是管理好项目,而不是去写代码。当你控制住不去写代码以后,你才能把注意力放到团队和项目上去,去领导团队。团队出现问题时,你能及时解决、及时调整。

所以,如果你带的项目进度吃紧时,你要做的不是去写代码,而是去帮助团队从其他角度想办法。具体怎么做,你可以参考我在《08 | 怎样平衡软件质量与时间成本范围的关系?》这篇文章里介绍的一些方法,看是不是可以用这些办法缓解进度压力。

  • 团队的成功,才是你的成功

我刚转型做管理的时候,问过老板一个问题:“是不是我把上级的工作做了,我就能升职了?”老板的回答很出乎我意料:“并不是你把上级的工作做了就能升职,而是你的下级都成长了,能替代你的位置了,你就可以升职了。”

这让我明白一个道理:作为一个管理者,团队的成功,才是你的成功。做程序员的时候,把代码写好就很成功了,但是转型做管理后,团队的成功和项目的成功,才是你的成功。

  • 形成自己的管理风格

我在刚开始工作的时候,当时的项目经理很厉害,对我们要求非常严厉,做错了可能就要挨批评,项目管理的很好。那段时间我也进步很大,所以我觉得他是一个很好的项目经理,我就想着自己以后也要像他一样去管理项目。

等到我开始管理项目时,我也想像他一样去严厉的对待下属,但我的性格是比较温和的,我没有办法去做到动不动就去责骂、批评下属,这也让我有了很大的困惑。

后来我尝试着结合自己的性格特点,更多地去激励、帮助下属。在这种管理风格下,整个团队的氛围很融洽,大家做事情也积极主动,一样达到了很好的管理目标。

所以说管理这种事,并不是只有一种风格一种方法,你完全可以根据自己的特点,找到适合自己的管理风格。

  • 坚持就是胜利

技术转型管理的过程,一定不会是一帆风顺的,你会面临很多挑战,会有非常大的压力。这时候最容易产生的冲动行为就是:“算了,还是回去写程序吧!”

我在转型的过程中也遭遇过非常大的压力,遇到过各种困难,掉了好多头发。我有过好多次想放弃的念头,最终还是咬咬牙,坚持了下来。

这样过了几年后,我再回头看当初觉得特别难、压力特别大的事情,现在看起来根本不算什么。如果我当初真的放弃了,恐怕再难迈过那道坎,完成转型。

一旦你已经下定决心要转型,就不要轻言放弃,坚持就是胜利。

总结

想要技术转型管理,首先从转变思维方式开始,从技术思维到管理思维,从关注细节到关注整体。然后去改变习惯,控制自己想写代码的冲动,多去从其他角度想办法。

要管理好一个项目,关键是要管理好项目中的人和事。对客户要管理好期望,对项目成员则通过合理的流程规范更好的一起协作;对于项目中事的管理就是对软件开发过程的管理,选择好开发模型很重要,然后就是制定好计划,按照计划推进,过程中不断的调整,并且管理好项目中的风险。

课后思考

你是否有想法从技术转型管理,打算怎么做?如果你正在准备转型或者转型中,有没有遇到什么困难,打算怎么去解决?欢迎在留言区与我分享讨论。

感谢阅读,如果你觉得这篇文章对你有一些启发,也欢迎把它分享给你的朋友。

精选留言(15)
  • Felix 👍(45) 💬(1)

    机缘巧合转管理已经快两年了,以下说说我的看法: 1. 大局观,我十分赞同老师的观点,我领导经常耳濡目染地这么教我们,我也觉得这是我转管理后的最大收获,不能像以前看着自己的一亩三分地,站在全局考虑问题;正如张一鸣说的那句,“工作时不分哪些是我该做的,哪些是我不该做的”,这句话对我影响很大,做事不设边界,才能我有更大的成长,而这些对管理来说尤为如此 2. 流程规范,接手管理后,发现虽然我们有一大堆流程规范的wiki,但很多形同虚设,我个人总结有以下几点问题:(1)不能很容易找到对应规范wiki (2)很多规范冗长复杂,不知所云 (3)流程规范太多,没时间看; 于是我第一步就是整理杂草丛生的wiki,先保证目录清晰,让大家按目录写wiki,对号入座,查阅起来方便有条理,接下来挑出重点的流程规范进行了简化微调,每周会重点强调1-2个,在本周工作中重点关注,并适当提醒,渐渐大家一起走入流程的正规,并也体会到了按流程规范走所带来的便捷 3. 管理该不该写代码,我觉的这事不能一棒子打死,我的观点有点像党的一句老话:从群众中来,到群众中去,在项目关键时刻负责一个小的Ticket,我觉的有以下几点好处:(1)因为平时的code review不可能面面俱到,这么做更加深入了解系统底层结构和代码,更加容易指导员工的技术细节问题 (2)让自己不是光说不练,纸上谈兵的领导,我觉得从我本身而言,可能中高层确实不必要,但我认为这对于一线管理还是很有必要的,能够树立威信,合作沟通更加顺畅 4. 自己的管理风格,关于大棒还是胡萝卜,确实不同的公司不同的团队应该有不同的管理风格,这里没有对与错,但我认为对于扁平化的互联网公司,各种大牛,严厉的风格是我不提倡的,像老师说的激励帮助下属,团队氛围融洽,大家自驱地做事情我认为更可取

    2019-03-19

  • 梦里是谁🌚 👍(22) 💬(2)

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

    2019-03-24

  • yu 👍(14) 💬(1)

    并不是你把上级的工作做了就能升职,而是你的下级都成长了,能替代你的位置了,你就可以升职了。 讓我想到《火影忍者》有一句話一直記得。 不是当上火影就能得到大家的认可,而是得到大家的认可才能当上火影。 只有提升別人的價值,才能更加展現自己的價值。

    2019-03-20

  • 风翱 👍(14) 💬(2)

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

    2019-03-19

  • alva_xu 👍(11) 💬(1)

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

    2019-03-20

  • 小老鼠 👍(8) 💬(1)

    毕竟管理职位少。如果在这家公司做了管理,脱离了技术,以后换工作会不会捡不起技术了?

    2019-09-11

  • 易林林 👍(7) 💬(1)

    我觉得管理者要做到的一点就是自律。首先管好自己,然后才能管好团队,做到言出必行、言而有信、正面积极,并给团队找准一个前进的方向,让所管理的团队能感受到工作的节奏和成长的空间,最大化的调动团队思想上和行动上的积极性。 提到技术转向管理,应该最大限度的利用在舒适区擅长的技能来辅助学习区的成长,最终将学习区变成你的舒适区,摒弃原有的过时的舒适区。所以,除非情况万分危及,否则我们不能轻易动用舒适区这样的杀手锏,伤人伤己,害而无利。曾经看到过一句话:跑出离起点100米后感到口渴了,离起点50米处有水,你是回去拿水呢还是继续跑?我觉得长久的问题不能图一时痛快来解决。 说白了,技术转向管理是眼界的变化,关注点的范围和程度的扩展,身体力行到运筹帷幄的升华,正所谓善战者无赫赫之功。

    2019-03-22

  • 川杰 👍(7) 💬(1)

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

    2019-03-20

  • hua168 👍(6) 💬(1)

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

    2019-03-19

  • titan 👍(5) 💬(2)

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

    2019-03-20

  • dancer 👍(4) 💬(1)

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

    2019-03-19

  • bearlu 👍(4) 💬(1)

    这篇文章,有把整个专栏串起来的作用。

    2019-03-19

  • javaadu 👍(3) 💬(1)

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

    2019-03-24

  • 舒偌一 👍(3) 💬(1)

    1、技术转管理,首先是有技术,接下来就是业务,技术、业务是基层管理人员的基础,没有这两个,上下怎么沟通?很容易就成为一个协调员,上级领导干预。 2、认知的转变,做技术只是解决单个问题,做管理是团结成员一起解决问题,共同完成团队目标。 3、一起制定制度,明确分工、职责、工作流程、完成标准。最好有一份对应的清单。 4、最重要的是团结成员,围绕共同目标做事,这个是管理风格了,有的是严厉的制度,有的是喝酒唱歌

    2019-03-21

  • 舒偌一 👍(3) 💬(1)

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

    2019-03-21