10 | 如果你想技术转管理，先来试试管好一个项目
该思维导图由 AI 生成，仅供参考
技术人员转型管理的障碍是什么？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
技术人员转型管理的关键在于从技术思维向管理思维的转变。本文分享了技术人员转型管理的障碍以及如何管理软件项目。作者指出，技术人员通常过于专注技术实现，忽视其他事务，因此需要具备大局观和关注项目整体的能力。建议技术人员先从管好一个项目开始，逐步转变思维，从技术思维到工程思维。文章强调了软件项目管理的两个维度：管好人和管好事。对于管好人，需要管理客户的期望和项目成员的紧密协作；对于管好事，需要选择适合项目的开发模式、制定项目计划、跟踪和控制计划，并做好风险管理。作者还提到了软件项目管理的知识内容很多，但建议在刚开始时先把管好人和管好事做好，然后逐步拓展到其他知识领域。整体而言，本文强调了技术人员转型管理的重要性，以及如何通过项目管理作为第一步来实现这一转型。文章还分享了一些经验教训，包括控制写代码的冲动、团队的成功即是个人的成功、形成自己的管理风格以及坚持不懈。这些经验对于技术人员转型管理具有重要的指导意义。
《软件工程之美》，新⼈⾸单¥59
全部留言(40)
- 最新
- 精选
- Felix机缘巧合转管理已经快两年了，以下说说我的看法： 1. 大局观，我十分赞同老师的观点，我领导经常耳濡目染地这么教我们，我也觉得这是我转管理后的最大收获，不能像以前看着自己的一亩三分地，站在全局考虑问题；正如张一鸣说的那句，“工作时不分哪些是我该做的，哪些是我不该做的”，这句话对我影响很大，做事不设边界，才能我有更大的成长，而这些对管理来说尤为如此 2. 流程规范，接手管理后，发现虽然我们有一大堆流程规范的wiki，但很多形同虚设，我个人总结有以下几点问题：（1）不能很容易找到对应规范wiki (2)很多规范冗长复杂，不知所云 (3)流程规范太多，没时间看； 于是我第一步就是整理杂草丛生的wiki，先保证目录清晰，让大家按目录写wiki，对号入座，查阅起来方便有条理，接下来挑出重点的流程规范进行了简化微调，每周会重点强调1-2个，在本周工作中重点关注，并适当提醒，渐渐大家一起走入流程的正规，并也体会到了按流程规范走所带来的便捷 3. 管理该不该写代码，我觉的这事不能一棒子打死，我的观点有点像党的一句老话：从群众中来，到群众中去，在项目关键时刻负责一个小的Ticket，我觉的有以下几点好处：（1）因为平时的code review不可能面面俱到，这么做更加深入了解系统底层结构和代码，更加容易指导员工的技术细节问题 （2）让自己不是光说不练，纸上谈兵的领导，我觉得从我本身而言，可能中高层确实不必要，但我认为这对于一线管理还是很有必要的，能够树立威信，合作沟通更加顺畅 4. 自己的管理风格，关于大棒还是胡萝卜，确实不同的公司不同的团队应该有不同的管理风格，这里没有对与错，但我认为对于扁平化的互联网公司，各种大牛，严厉的风格是我不提倡的，像老师说的激励帮助下属，团队氛围融洽，大家自驱地做事情我认为更可取
作者回复: 👍这个补充留言很有料 写不写代码其实也算管理风格的一部分，只要把握好度也很好的。
2019-03-1944 
梦里是谁🌚来现在公司十个多月，技术人员从最初一个我，到十个人，都是我亲自面试进来的，跟作者一样我也是个温和的人，没有过多的批评，甚至有时帮他们完成任务。他们遇到问题时，我一般也是授人以渔，教会他们解决办法和思路，过完年公司融资不善，半个月前公司整体裁人，我们部门裁掉6人。上周五又继续裁掉3人，目前只剩下我自己。离别聚餐的时候每个人都表示舍不得这个团队，有人私下说如果遇到好公司有条件了想要我们都过去，还让我带领他们，也有人说如果公司好了希望再回来。感觉需要一段时间才能恢复自己的心情，虽然表面没有什么情绪，但是内心真的很。。。作者回复: 心情真的能理解！看远些，天下没有不散的筵席，以后还有一起合作的机会。目前大环境不好，个人能做的确实有限。 一个管理者，给下属最好的礼物就是帮助他们成长，这也是他们即使离开还真心感激你的原因👍 祝大家都好！ --- 追加回复：天大的王老师想联系您，这是他的邮箱：wangzan(at)tju.edu.cn，如果看到麻烦给他发个信。
2019-03-24222
yu并不是你把上级的工作做了就能升职，而是你的下级都成长了，能替代你的位置了，你就可以升职了。 讓我想到《火影忍者》有一句話一直記得。 不是当上火影就能得到大家的认可，而是得到大家的认可才能当上火影。 只有提升別人的價值，才能更加展現自己的價值。作者回复: 👍是的，在团队里面，能帮助提升其他人的价值的人价值最大
2019-03-2014
风翱团队的成功，才是你的成功. 以前也是这个观点，但自身的例子，让我有些动摇。把下级培养起来了，结果不是升职，而是上级越来越把我边沿化，把我培养起来的人（在公开的场合直接宣布在我之上，私下只有我、上级和原来的下属，就说会列出权责范围，各自负责不同的地方，结果一个多月过去了，也没个下文）。对于这种情况，怎么调整自己呢？作者回复: 心情完全能理解，但建议还是看长远些。 人生不只是一个下属不只是一个老板也不只是一个项目。 以前我也纠结过这问题，现在不纠结了。因为我不止能培养好一个下属还能培养更多的下属，我能做好一个项目还能做好更多项目，我不需要靠一个老板的赏识与否来证明自己。
2019-03-19214- alva_xu关于技术转管理，先从项目管理开始。这个观点我极其赞同。以下我谈谈自己的想法。 1，老师举的是软件开发项目管理的例子，假定的项目经理是有开发技术的，所以需要克制自己不要有写代码的冲动，这一点我极其赞同。但假如项目经理以前并不是写代码的，这时候怎么办？我倒是觉得，应该学点代码，尝试写点代码，深入理解软件开发框架，培养点软件架构思想，才能充分理解开发人员的境况，更容易和自己团队甚至客户进行交流。同时无论你过去是开发大牛、还是应用架构师、领域专家、还是基础架构师，除非人员安排如此，否则，千万不要越俎代庖，把这些事情交给负责这些事情的人去做，你可以做的就是帮助指导，而且尽量要从方法上去指导，“授人以鱼不如授人以渔”。特别是一个比较固定的团队，培养一个人的成长比样样事必躬亲要好。 2，管理牵涉到”人““工具””流程“三个部分的使用。项目经理首先需要学一些管理学的知识，如何激发”人“的潜力已完成目标是管理的最主要目的，所以一些管理理念比如MBO，管理方法（沟通技巧）都得学一点。对于”工具“，好的工具和差的工具效果不同，但更主要的是要用好工具，比如敏捷模式中，像Jira，或者VSTS等都是很好的管理工具，也就是老师讲的ticket工具，但怎么用好它，需要项目经理在团队内外进行培训推广，常抓不懈。还要考虑怎么把“流程”固化到工具中，那么项目管理就可以行云流水了，所谓子在川上曰，逝者如斯夫！ 3，当“人”“工具”“流程”都发挥了它们的作用的时候，项目经理就需要凭借自己的知识和经验、善于发现风险，管控风险。这时候，我觉得风险管理是项目经理最大的责任。特别是控制好“范围”（防止项目过程中范围扩大或者变小），“成本”和“时间”，以最终达到合理成本下按时交付完整的达到质量要求的项目交付物。 以上几点，也是我从基础架构规划实施、然后做基础架构项目，现在管理软件开发项目好多年来的对于项目管理的一些经验，和大家共享，也请老师点评。
作者回复: 你这不止是总结，很多内容补充的特别特别好👍 非技术出身，反而是要学习技术，要信任技术 流程工具和风险管理，后面两篇还会继续讲到，到时候还请继续点评讲解🤝
2019-03-2011 
小老鼠毕竟管理职位少。如果在这家公司做了管理，脱离了技术，以后换工作会不会捡不起技术了？作者回复: 确实有这个问题，建议即使转管理岗位，也不要脱离一线技术，尤其是业余时间，应该保持对技术的学习和应用。 比如我在做管理岗位时，回家后也会写一些代码，后来出国要转技术岗，很快能捡回来。
2019-09-118
易林林我觉得管理者要做到的一点就是自律。首先管好自己，然后才能管好团队，做到言出必行、言而有信、正面积极，并给团队找准一个前进的方向，让所管理的团队能感受到工作的节奏和成长的空间，最大化的调动团队思想上和行动上的积极性。 提到技术转向管理，应该最大限度的利用在舒适区擅长的技能来辅助学习区的成长，最终将学习区变成你的舒适区，摒弃原有的过时的舒适区。所以，除非情况万分危及，否则我们不能轻易动用舒适区这样的杀手锏，伤人伤己，害而无利。曾经看到过一句话：跑出离起点100米后感到口渴了，离起点50米处有水，你是回去拿水呢还是继续跑？我觉得长久的问题不能图一时痛快来解决。 说白了，技术转向管理是眼界的变化，关注点的范围和程度的扩展，身体力行到运筹帷幄的升华，正所谓善战者无赫赫之功。作者回复: 谢谢补充，非常非常好👍
2019-03-227
川杰老师，我的目标是成为架构师，想问的是，在您看来，架构师是否也属于管理者的范畴？ 因为他需要对产品的整个框架的负责，进而涉及到对每个人的代码的管理，必要时还要给带领团队成员去做重难点问题的攻坚。 那么对于架构师而言，是更偏向技术还是管理呢？作者回复: 我觉得架构师和管理有相通的也有不同的，简单说一下我的观点： 都需要大局观 都需要好的沟通能力，让团队清晰的理解自己的意图 都需要用好流程和工具 都要善于“分而治之”，把复杂的问题拆分成小的具体的问题 不同之处在于 项目经理更多的是跟人打交道，对项目负责 架构设计更多是专注技术，对架构负责 两者互为补充，架构师有项目管理能力、项目经理有架构能力，都是非常好的
2019-03-207
hua168老师能否跟我们没有做过技术管理的人讲一下技术管理的工作内容、日常、关键性的会议、总结、文档等等… 前不久，我前老总找我说可能打算开个公司做个电商网，我负责管理技术，其它他负责…… 我压力顿时巨大，不得不学开发（java编程），没做过技术管理，生怕不合格，我也矛盾中，如果我接了管不好，那脸可丢大了，也不知道管理日常是什么，要做那些工作…作者回复: 就像我文章中说的，管理呢，就是管人管事，你看很多老板也许不懂技术，但是能管得住懂技术的人。 你这也一样，只要下面有懂技术的人，愿意帮你，那你就可以搞得定了。 管理知识没有那么难，多学习理论知识，多像有经验的人请教，在实战中积累经验。
2019-03-196
titan我曾在华为做了快七年的架构师，现在转管理也已经两年了，但是都是做的小公司的技术总监，我遇到的最大的问题，我感觉还是小公司如何进行技术管理的问题？我所在的公司，开发人员多的40、50人，少的10多个人，这个阶段，是用制度来进行管理，还是人来管理比较合适？当然，这个问题可能有点超出软件工程的范畴了。作者回复: 我觉得无论大小公司，一定都要多用合理制度流程，多用工具，摆脱对人的过度依赖，只是在设计流程规范时，要充分结合公司特点、项目特点。 比如说小公司老板权力很大，有些流程普通员工有效，老板直接无视了，你还得做好隔离措施，让他不要破坏流程。 比如说大公司很多工具、系统都是自建，小公司就不如买来的合算。 大公司各种会议和文档相对多很多，小公司这方面就可以多精简，但必要的也不能少 大公司用瀑布模型开发，一个项目几年耗得起，小公司还是敏捷一点，早点能看到产出更好 将来有一天，小公司也会变成大公司，如果你之前没有做好制度建设，将来团队壮大，项目多了，你可能就会成为管理瓶颈。
2019-03-2025
