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

Mar 19, 2019

10 | 如果你想技术转管理，先来试试管好一个项目-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

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

2019-03-19 宝玉来自北京

《软件工程之美》

课程介绍



讲述：宝玉

时长14:15大小13.02M



你好，我是宝玉，我今天与你分享的主题是：如果你想技术转管理，先来试试管好一个项目。
技术转管理，是很多技术人员的梦想，所以经常有人问我，怎么样才能转型管理？
项目管理，是最基础的管理，既要管理一个项目，又要协调整个团队一起，完成共同的目标。
我的管理转型就是从项目管理开始的，在从技术转型项目管理的过程中，让我从以前专注于局部技术实现，逐步转向关注项目整体；从个人的单打独斗，到借助整个团队的力量一起完成一个项目。
一直到后来做开发总监要去管理整个开发部门，发现还是一样绕不开要管理项目，只是从直接管项目变成了间接管项目而已。
所以我一般会建议：如果你想技术转管理，先试试管好一个项目。项目管理通常是技术人员转型管理的第一步，也是非常关键的一步！
技术人员转型管理的障碍是什么？很多人认为技术人员是不适合做管理的，包括网上也有很多对程序员的刻板印象，比如说：极客、木纳、不善交际、头发少、穿格子衫……
而我了解的程序员却不是这样子的，他们都很聪明，学习能力强，而情商这些其实和其他职业群体是没有区别的。
那么为什么程序员会给人这种刻板印象呢？
一方面原因是这个群体勇于自黑，不介意这些印象；另一方面则是他们过于专注技术实现，沉浸于细节中，而忽视了其他事情。
程序员总是想着如何技术实现、用什么语言框架、怎么提高效率……要钻研技术，这些是非常好的优点，但是要转管理，这反而会是一种障碍。
因为管理，最重要的一点就是大局观，要能从整个项目的角度，从整个团队的角度去思考，去确定方向，去发现问题，对问题及时解决及时调整。
但是当你把注意力都放在技术细节上，就容易忽视其他事情，例如和其他人之间的沟通、不关心当前项目进展。
就像有人说的：
关注细节的，是工程师；
关注过程的，是项目经理；
关注结果的，是老板。
所以，如果你要技术转管理，可以先从管好一个项目开始。这也是为什么我在专栏一开始，就建议你要逐步转变思维，从技术思维到工程思维，不要仅仅局限于自己负责的那一个小模块，而是要多从项目的整体去思考。
怎么样去管理一个软件项目？软件项目管理涉及知识不少，既有传统的项目管理知识，又需要掌握软件工程的知识，所以很多人一谈到项目管理就觉得很难很复杂。
我在专栏中一直强调“道、术、器”，对于很多知识，如果我们能总结出其中的“道”，再去看很多问题，其实就没那么复杂了。
就软件项目管理来说，“道”就是管好人、管好事。如果从这两个维度去看如何管理项目，就会发现其实并不难，有很多“术”可以为我们所用。
怎样管好软件项目中的人？软件项目管理的一个维度是管人。项目管理中的人，主要涉及两类：客户和项目成员。
1. 管理好客户的预期
客户，就是会使用你软件产品的人，通常也是给你项目出钱的人。
对于客户的管理，就是对于客户期望值的管理，如果你项目的结果高于客户的期望，那么就可以说你的项目就是成功的，如果没有达到客户的期望，可能就是不成功的。
想要满足客户预期，通常来说，就是你能在项目的质量、范围、时间和成本上达到要求。
质量达标：交付产品是高质量的，满足客户需求的。
完整交付：按照约定的功能范围交付最终产品。
按时交付：项目按照客户认可的进度完成。
预算之内：在预算内完成项目。
这四个要素，并不是说必须都要满足，其实很多时候是可以协商的，重点是要达到一个平衡，怎么达到平衡？具体你可以参考《08 | 怎样平衡软件质量与时间成本范围的关系？》，我已经在这篇文章中进行了详细的解答。
2. 用流程和规范让项目成员一起紧密协作
项目成员，也就是帮助你一起完成项目的人。
对于项目成员的管理，不需要过多依赖人的管理，否则项目经理就会成为项目管理的瓶颈。所以更多要落实到流程和工具上。
好的项目管理，不需要直接去管人，而是管理好流程规范；项目成员不需要按照项目经理的指令做事，而是遵循流程规范。
合适的项目管理工具，也可以简化流程，保障流程的执行，提高效率。
关于具体怎样制定流程规范，我会后续更新的文章《12 | 流程和规范：红绿灯不是约束，而是用来提高效率》中有更多介绍。
关于项目管理的工具，也会在《14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决》中有详细介绍。另外，你也可以先参考我在《06 | 大厂都是如何应用敏捷开发的？（上）》中提到的部分案例。
怎样管好软件项目中的事？软件项目管理的另一个维度就是管事。软件项目中的事，是指要完成项目目标，在整个开发过程中所产生的一系列任务。对项目中事情的管理，本质上就是对软件开发过程的管理。
1. 选择适合项目的开发模式
软件项目的过程管理，和其他工程项目完全不一样，有其独特性，好在软件工程对这些过程的开发模式都已经有了很好的总结，我们直接借用就可以了。
选择好开发模式，才好确定后续的一系列问题，例如流程规范、使用什么工具，如何制定项目计划等。
所以对软件项目过程的管理，首先就是要根据项目特点选取合适的开发模式，是敏捷开发还是瀑布模型或者瀑布模型的衍生模型？是一步到位还是逐步迭代？
对于开发模式的选择，可以参考《03 | 瀑布模型：像工厂流水线一样把软件开发分层化》《04 | 瀑布模型之外，还有哪些开发模型？》和《05 | 敏捷开发到底是想解决什么问题？》的内容。
当然，开发模式选好了后，还需要配套的流程规范，以及合适的工具，以保障开发模式的执行。
2. 制定好项目计划
凡事预则立不预则废，在选择好开发模式后，紧接着就是要做好项目计划，有了项目计划，才能有计划有目的地去推动项目进展，出现问题也能及时发现、及时调整。
对于如何制定计划，我将在下一篇更新的文章《11 | 项目计划：代码未动，计划先行》中进行详细讲解。
3. 对计划进行跟踪和控制，同时做好风险管理
计划制定后，并不是说事情就会完全按照我们设想的进行，实际执行难免会和计划有些出入，所以还需要对计划进行跟踪和控制。当项目的推进过程中，如果计划有出入时，需要分析原因，对计划做出调整。
同时，也不能盲目乐观，对于项目过程中可能存在的风险要进行识别，做好 B 计划，这样一旦风险发生变成问题，可以及时应对，减少风险导致的损失。有关风险管理的内容，可以参考《15 | 风险管理：不能盲目乐观，凡事都应该有 B 计划》。
管好人、管好事，你就能管好软件项目。除了上面介绍的一些项目管理知识，涉及软件项目管理的知识内容还有很多。这里并不是说其他知识内容不重要，而是在刚开始的时候，先把这些事情做好，可以保证项目管理不会出现大的偏差，然后逐步拓展到其他知识领域。
在这里，我把前面说的内容做了个简单的思维导图，希望可以对你的项目管理转型起到一定的帮助作用。
技术转管理的一些经验教训分享技术转管理的路上肯定不会是一帆风顺的，要自己踩过很多坑才能成长，我这里也给你分享一点经验教训，希望能帮助你少走一点弯路。
控制你想写代码的冲动
我给每一个刚从技术转型管理的同学的第一个建议都是一样的，那就是：“不要写代码，不要写代码，不要写代码，控制你想自己动手写代码的冲动。”
前面我说过技术人员转型管理的最大障碍是什么，那就是过于关注技术，而忽略了其他事情。从技术转型管理，是个巨大的转变，这种思维的转变是很难一蹴而就的。
对于程序员来说，写代码是自己的“舒适区”，而管理则是“学习区”或“恐慌区”，在转型的过程中，特别容易回到舒适区。
比如你看某个接手你的程序员代码写的实在是不够好，那是你最熟悉的，你只要一小时就写完了，而他要一整天的时间，还没有你写的质量好，你会很有冲动去帮他完成。
比如说在项目进度吃紧的时候，你可能第一想法就是自己去写代码帮助团队赶上进度。
但是，你要知道，当你转型管理后，你的主要职责就是管理，而不是写程序。如果你还是把大部分时间用在写程序上，那么你就很容易忽略项目中的问题。比如没有去关注项目的进展、目前项目的瓶颈、和客户以及其他项目组之间的沟通协调等。
这就是为什么你第一步是要控制自己写代码的冲动。作为一个项目管理者，你的第一要务是管理好项目，而不是去写代码。当你控制住不去写代码以后，你才能把注意力放到团队和项目上去，去领导团队。团队出现问题时，你能及时解决、及时调整。
所以，如果你带的项目进度吃紧时，你要做的不是去写代码，而是去帮助团队从其他角度想办法。具体怎么做，你可以参考我在《08 | 怎样平衡软件质量与时间成本范围的关系？》这篇文章里介绍的一些方法，看是不是可以用这些办法缓解进度压力。
团队的成功，才是你的成功
我刚转型做管理的时候，问过老板一个问题：“是不是我把上级的工作做了，我就能升职了？”老板的回答很出乎我意料：“并不是你把上级的工作做了就能升职，而是你的下级都成长了，能替代你的位置了，你就可以升职了。”
这让我明白一个道理：作为一个管理者，团队的成功，才是你的成功。做程序员的时候，把代码写好就很成功了，但是转型做管理后，团队的成功和项目的成功，才是你的成功。
形成自己的管理风格
我在刚开始工作的时候，当时的项目经理很厉害，对我们要求非常严厉，做错了可能就要挨批评，项目管理的很好。那段时间我也进步很大，所以我觉得他是一个很好的项目经理，我就想着自己以后也要像他一样去管理项目。
等到我开始管理项目时，我也想像他一样去严厉的对待下属，但我的性格是比较温和的，我没有办法去做到动不动就去责骂、批评下属，这也让我有了很大的困惑。
后来我尝试着结合自己的性格特点，更多地去激励、帮助下属。在这种管理风格下，整个团队的氛围很融洽，大家做事情也积极主动，一样达到了很好的管理目标。
所以说管理这种事，并不是只有一种风格一种方法，你完全可以根据自己的特点，找到适合自己的管理风格。
坚持就是胜利
技术转型管理的过程，一定不会是一帆风顺的，你会面临很多挑战，会有非常大的压力。这时候最容易产生的冲动行为就是：“算了，还是回去写程序吧！”
我在转型的过程中也遭遇过非常大的压力，遇到过各种困难，掉了好多头发。我有过好多次想放弃的念头，最终还是咬咬牙，坚持了下来。
这样过了几年后，我再回头看当初觉得特别难、压力特别大的事情，现在看起来根本不算什么。如果我当初真的放弃了，恐怕再难迈过那道坎，完成转型。
一旦你已经下定决心要转型，就不要轻言放弃，坚持就是胜利。
总结想要技术转型管理，首先从转变思维方式开始，从技术思维到管理思维，从关注细节到关注整体。然后去改变习惯，控制自己想写代码的冲动，多去从其他角度想办法。
要管理好一个项目，关键是要管理好项目中的人和事。对客户要管理好期望，对项目成员则通过合理的流程规范更好的一起协作；对于项目中事的管理就是对软件开发过程的管理，选择好开发模型很重要，然后就是制定好计划，按照计划推进，过程中不断的调整，并且管理好项目中的风险。
课后思考你是否有想法从技术转型管理，打算怎么做？如果你正在准备转型或者转型中，有没有遇到什么困难，打算怎么去解决？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 6

提建议

09 | 为什么软件工程项目普遍不重视可行性分析？

11 | 项目计划：代码未动，计划先行

 写留言

精选留言(40)

Felix
2019-03-19
机缘巧合转管理已经快两年了，以下说说我的看法： 1. 大局观，我十分赞同老师的观点，我领导经常耳濡目染地这么教我们，我也觉得这是我转管理后的最大收获，不能像以前看着自己的一亩三分地，站在全局考虑问题；正如张一鸣说的那句，“工作时不分哪些是我该做的，哪些是我不该做的”，这句话对我影响很大，做事不设边界，才能我有更大的成长，而这些对管理来说尤为如此 2. 流程规范，接手管理后，发现虽然我们有一大堆流程规范的wiki，但很多形同虚设，我个人总结有以下几点问题：（1）不能很容易找到对应规范wiki (2)很多规范冗长复杂，不知所云 (3)流程规范太多，没时间看；于是我第一步就是整理杂草丛生的wiki，先保证目录清晰，让大家按目录写wiki，对号入座，查阅起来方便有条理，接下来挑出重点的流程规范进行了简化微调，每周会重点强调1-2个，在本周工作中重点关注，并适当提醒，渐渐大家一起走入流程的正规，并也体会到了按流程规范走所带来的便捷 3. 管理该不该写代码，我觉的这事不能一棒子打死，我的观点有点像党的一句老话：从群众中来，到群众中去，在项目关键时刻负责一个小的Ticket，我觉的有以下几点好处：（1）因为平时的code review不可能面面俱到，这么做更加深入了解系统底层结构和代码，更加容易指导员工的技术细节问题（2）让自己不是光说不练，纸上谈兵的领导，我觉得从我本身而言，可能中高层确实不必要，但我认为这对于一线管理还是很有必要的，能够树立威信，合作沟通更加顺畅 4. 自己的管理风格，关于大棒还是胡萝卜，确实不同的公司不同的团队应该有不同的管理风格，这里没有对与错，但我认为对于扁平化的互联网公司，各种大牛，严厉的风格是我不提倡的，像老师说的激励帮助下属，团队氛围融洽，大家自驱地做事情我认为更可取
展开
作者回复: 👍这个补充留言很有料写不写代码其实也算管理风格的一部分，只要把握好度也很好的。
40
梦里是谁🌚
2019-03-24
来现在公司十个多月，技术人员从最初一个我，到十个人，都是我亲自面试进来的，跟作者一样我也是个温和的人，没有过多的批评，甚至有时帮他们完成任务。他们遇到问题时，我一般也是授人以渔，教会他们解决办法和思路，过完年公司融资不善，半个月前公司整体裁人，我们部门裁掉6人。上周五又继续裁掉3人，目前只剩下我自己。离别聚餐的时候每个人都表示舍不得这个团队，有人私下说如果遇到好公司有条件了想要我们都过去，还让我带领他们，也有人说如果公司好了希望再回来。感觉需要一段时间才能恢复自己的心情，虽然表面没有什么情绪，但是内心真的很。。。
展开
作者回复: 心情真的能理解！看远些，天下没有不散的筵席，以后还有一起合作的机会。目前大环境不好，个人能做的确实有限。一个管理者，给下属最好的礼物就是帮助他们成长，这也是他们即使离开还真心感激你的原因👍 祝大家都好！ --- 追加回复：天大的王老师想联系您，这是他的邮箱：wangzan(at)tju.edu.cn，如果看到麻烦给他发个信。
共 2 条评论
22
yu
2019-03-20
并不是你把上级的工作做了就能升职，而是你的下级都成长了，能替代你的位置了，你就可以升职了。讓我想到《火影忍者》有一句話一直記得。不是当上火影就能得到大家的认可，而是得到大家的认可才能当上火影。只有提升別人的價值，才能更加展現自己的價值。
展开
作者回复: 👍是的，在团队里面，能帮助提升其他人的价值的人价值最大
14
六维
2019-03-19
团队的成功，才是你的成功. 以前也是这个观点，但自身的例子，让我有些动摇。把下级培养起来了，结果不是升职，而是上级越来越把我边沿化，把我培养起来的人（在公开的场合直接宣布在我之上，私下只有我、上级和原来的下属，就说会列出权责范围，各自负责不同的地方，结果一个多月过去了，也没个下文）。对于这种情况，怎么调整自己呢？
作者回复: 心情完全能理解，但建议还是看长远些。人生不只是一个下属不只是一个老板也不只是一个项目。以前我也纠结过这问题，现在不纠结了。因为我不止能培养好一个下属还能培养更多的下属，我能做好一个项目还能做好更多项目，我不需要靠一个老板的赏识与否来证明自己。
共 2 条评论
13
alva_xu
2019-03-20
关于技术转管理，先从项目管理开始。这个观点我极其赞同。以下我谈谈自己的想法。 1，老师举的是软件开发项目管理的例子，假定的项目经理是有开发技术的，所以需要克制自己不要有写代码的冲动，这一点我极其赞同。但假如项目经理以前并不是写代码的，这时候怎么办？我倒是觉得，应该学点代码，尝试写点代码，深入理解软件开发框架，培养点软件架构思想，才能充分理解开发人员的境况，更容易和自己团队甚至客户进行交流。同时无论你过去是开发大牛、还是应用架构师、领域专家、还是基础架构师，除非人员安排如此，否则，千万不要越俎代庖，把这些事情交给负责这些事情的人去做，你可以做的就是帮助指导，而且尽量要从方法上去指导，“授人以鱼不如授人以渔”。特别是一个比较固定的团队，培养一个人的成长比样样事必躬亲要好。 2，管理牵涉到”人““工具””流程“三个部分的使用。项目经理首先需要学一些管理学的知识，如何激发”人“的潜力已完成目标是管理的最主要目的，所以一些管理理念比如MBO，管理方法（沟通技巧）都得学一点。对于”工具“，好的工具和差的工具效果不同，但更主要的是要用好工具，比如敏捷模式中，像Jira，或者VSTS等都是很好的管理工具，也就是老师讲的ticket工具，但怎么用好它，需要项目经理在团队内外进行培训推广，常抓不懈。还要考虑怎么把“流程”固化到工具中，那么项目管理就可以行云流水了，所谓子在川上曰，逝者如斯夫！ 3，当“人”“工具”“流程”都发挥了它们的作用的时候，项目经理就需要凭借自己的知识和经验、善于发现风险，管控风险。这时候，我觉得风险管理是项目经理最大的责任。特别是控制好“范围”（防止项目过程中范围扩大或者变小），“成本”和“时间”，以最终达到合理成本下按时交付完整的达到质量要求的项目交付物。以上几点，也是我从基础架构规划实施、然后做基础架构项目，现在管理软件开发项目好多年来的对于项目管理的一些经验，和大家共享，也请老师点评。
展开
作者回复: 你这不止是总结，很多内容补充的特别特别好👍 非技术出身，反而是要学习技术，要信任技术流程工具和风险管理，后面两篇还会继续讲到，到时候还请继续点评讲解🤝
10
小老鼠
2019-09-11
毕竟管理职位少。如果在这家公司做了管理，脱离了技术，以后换工作会不会捡不起技术了？
作者回复: 确实有这个问题，建议即使转管理岗位，也不要脱离一线技术，尤其是业余时间，应该保持对技术的学习和应用。比如我在做管理岗位时，回家后也会写一些代码，后来出国要转技术岗，很快能捡回来。
7
易林林
2019-03-22
我觉得管理者要做到的一点就是自律。首先管好自己，然后才能管好团队，做到言出必行、言而有信、正面积极，并给团队找准一个前进的方向，让所管理的团队能感受到工作的节奏和成长的空间，最大化的调动团队思想上和行动上的积极性。提到技术转向管理，应该最大限度的利用在舒适区擅长的技能来辅助学习区的成长，最终将学习区变成你的舒适区，摒弃原有的过时的舒适区。所以，除非情况万分危及，否则我们不能轻易动用舒适区这样的杀手锏，伤人伤己，害而无利。曾经看到过一句话：跑出离起点100米后感到口渴了，离起点50米处有水，你是回去拿水呢还是继续跑？我觉得长久的问题不能图一时痛快来解决。说白了，技术转向管理是眼界的变化，关注点的范围和程度的扩展，身体力行到运筹帷幄的升华，正所谓善战者无赫赫之功。
展开
作者回复: 谢谢补充，非常非常好👍
7
titan
2019-03-20
我曾在华为做了快七年的架构师，现在转管理也已经两年了，但是都是做的小公司的技术总监，我遇到的最大的问题，我感觉还是小公司如何进行技术管理的问题？我所在的公司，开发人员多的40、50人，少的10多个人，这个阶段，是用制度来进行管理，还是人来管理比较合适？当然，这个问题可能有点超出软件工程的范畴了。
作者回复: 我觉得无论大小公司，一定都要多用合理制度流程，多用工具，摆脱对人的过度依赖，只是在设计流程规范时，要充分结合公司特点、项目特点。比如说小公司老板权力很大，有些流程普通员工有效，老板直接无视了，你还得做好隔离措施，让他不要破坏流程。比如说大公司很多工具、系统都是自建，小公司就不如买来的合算。大公司各种会议和文档相对多很多，小公司这方面就可以多精简，但必要的也不能少大公司用瀑布模型开发，一个项目几年耗得起，小公司还是敏捷一点，早点能看到产出更好将来有一天，小公司也会变成大公司，如果你之前没有做好制度建设，将来团队壮大，项目多了，你可能就会成为管理瓶颈。
共 2 条评论
5
川杰
2019-03-20
老师，我的目标是成为架构师，想问的是，在您看来，架构师是否也属于管理者的范畴？因为他需要对产品的整个框架的负责，进而涉及到对每个人的代码的管理，必要时还要给带领团队成员去做重难点问题的攻坚。那么对于架构师而言，是更偏向技术还是管理呢？
作者回复: 我觉得架构师和管理有相通的也有不同的，简单说一下我的观点：都需要大局观都需要好的沟通能力，让团队清晰的理解自己的意图都需要用好流程和工具都要善于“分而治之”，把复杂的问题拆分成小的具体的问题不同之处在于项目经理更多的是跟人打交道，对项目负责架构设计更多是专注技术，对架构负责两者互为补充，架构师有项目管理能力、项目经理有架构能力，都是非常好的
6
hua168
2019-03-19
老师能否跟我们没有做过技术管理的人讲一下技术管理的工作内容、日常、关键性的会议、总结、文档等等… 前不久，我前老总找我说可能打算开个公司做个电商网，我负责管理技术，其它他负责…… 我压力顿时巨大，不得不学开发（java编程），没做过技术管理，生怕不合格，我也矛盾中，如果我接了管不好，那脸可丢大了，也不知道管理日常是什么，要做那些工作…
展开
作者回复: 就像我文章中说的，管理呢，就是管人管事，你看很多老板也许不懂技术，但是能管得住懂技术的人。你这也一样，只要下面有懂技术的人，愿意帮你，那你就可以搞得定了。管理知识没有那么难，多学习理论知识，多像有经验的人请教，在实战中积累经验。
5
dancer
2019-03-19
管人和管事，言简意赅，受教了! 但是对是否写代码，我个人的看法是，对于一个一线技术管理，比如不到十人技术团队的leader，我觉得时刻保持学习新技术，写写代码还是有必要的。好处一是做技术选型或者评审设计的时候，不会把团队带跑；好处二是做技术决策的时候，更有说服力。总儿言之，就是要有一定的技术领导力。
作者回复: 你这个补充很好，我在文中说的有点绝对了，客观一点说法应该是尽可能保持一个合适的比例！但管理的团队越大，职责越多，那么要写的代码比例就要越少。
4
javaadu
2019-03-24
1. 不同的岗位有不同的职责，基层管理者的职责并不是单纯的管理，要兼具技术深度、技术视野、项目管理、团队管理等技能。 2. 关于“写不写代码”的讨论，作者说这句话的意思是，项目管理者要明白，写代码并不是万能药，不能过分得关注细节，要跳出来，看全局，要明白自己的职责——管理项目过程、控制风险，拿到结果。至于说是不是要写代码，那是另外一个问题，阿里现在已经取消了技术线的纯粹的管理岗位，就是希望技术线的基层领导者都不要把技术丢掉，要能跳出来看全局，同时也能带领团队打硬仗。 3. 我有转型管理的计划，我希望自己能够实现从个人的成功到团队的成功，个人的成功，原因是：个人的成功，影响力有限，团队的成功才能完成更大的成就。我计划按照老师说的，从项目管理入手。遇到的困难就是自己的大局观不够，一冲动就喜欢自己上，这样的情况很不好：自己累的要死，还没什么成就感，然后团队其他成员也得不到充分的的锻炼。希望在后面的工作中，如果有项目管理的机会，自己能够改善自己的大局观。
展开
作者回复: 谢谢对于代码部分的补充，确实不是要丢掉技术，而是不要太过于技术👍 大局观需要一点点培养，能意识到问题在哪是很重要的一步。祝转型顺利
3
舒偌一
2019-03-21
目标的一致性是遇到的一个困难，公司没有激励制度，导致项目经理和组员目标不一致，如何解决这个问题很挠头。
作者回复: 目标一致性一个方法是多一对一沟通，你了解组员想法，组员知道你的期望另一个就是不必依赖于公司现有制度，自己创造激励制度，激励制度并不一定要花钱或者花很多钱，有时候正式的表扬比钱还有价值
3
hua168
2019-03-19
技术管理是不是: 1. 一定懂开发，参与过项目：这样你才知道用什么技术，开发某功能要花多久时间？ 2.当个项目经理：这样你有管理意识、沟通、任务分解及分配，懂得去全局看问题，更多的思考？ 3.思想和目光从深度向广度去转变：比如当前主流的技术及实现原理、架构师角度看问题、技术发展的趋势等，从局部观转到变成大局观如果能看懂代码，没做过项目管理/经理，能直接跳做技术管理吗？会不会变成外行人领导内行人？
展开
作者回复: 1. 需要懂一点开发，不需要特别深入，这样对方向和细节上会掌握的更好，最重要还是要有得力的技术干将 2. 不仅是项目经理，所有管理岗都要求更多的全局思考 3. 架构技术这些可选项，可以由架构师代劳项目经理对于代码要求没那么高，重要的是能找到技术好的人帮你。
3
bearlu
2019-03-19
这篇文章，有把整个专栏串起来的作用。
作者回复: 🤝
3
zhxilin℃+
2019-03-19
老师关于舒适区的论述非常深刻！做技术管理前提是得有足够多的技术积累和能力，提高自己的技术水平、编程思想、解决问题的能力也是程序员的必经之路，绝不能片面地认为自己想成为技术管理就不必学习技术，这是个误区！稳扎稳打，步步为营，才能进步。
作者回复: 👍嗯，懂技术对于做技术管理会有很多帮助。当然也不要对技术过于沉迷和过于自信：）
3
aya
2019-03-19
请问宝玉老师，我在技术转型管理时遇到2个问题： 1、本身项目很紧急，下面的人又并不积极对待，为了尽快完成只能自己写代码尽快上线，形成恶性循环。 2、大领导对我技术不错的印象根深蒂固，总是直接指挥我们项目，为了进度，让我尽快开发，等上线后再让其他人人学习。我也比较矛盾
展开
作者回复: 也是几点建议： 1. 招人、开人、培养人是持续要做的事情，必须要有人能替代你的那部分开发工作 2. 需要利用项目管理知识去砍需求、去要资源、去争取时间 3. 把写代码的时间和项目管理的时间要分开，例如上午专注项目管理事宜，下午专注于写代码，尽可能不要混一起 4. 和领导也要多一对一沟通，让他知道你可以做好
共 2 条评论
3
AntLoin
2019-03-19
针对一些曾经贡献大的技术怎么管理呢？然而传统思维模式和产品迭代模式遗留的一些诟病，很难用新环境、新模式让他们去做改变。（这里并不是否定以前的模式）比如：对新推出的KPI这类漠不关心、对整个团队表现不出积极的面，反而带来了一些不好的点和面，但是做东西质量相比其他又高；这类怎么去处理和更好的提升整个团队的战斗力、协作力。
作者回复: 几点建议： 1. 多一对一沟通，了解他的诉求，让他了解你的期望 2. 尝试安排一些有挑战的任务 3. 充分发挥其优势 4. “鲶鱼效应”，招聘技术相当的或者更高的，减少其不可替代性如果负面因素较多，可考虑： 5. 隔离到某个项目中，避免对其他人造成负面效果 6. 如果负面影响大于正向贡献，劝退也是个方案
3
calvins
2019-11-08
一线管理最难的是团队磨合，了解成员的心态，能力，特长，带动气氛，保持团队凝聚力才是最重要的，既要注重结果，也要注重过程。合适的人干合适的事，不然很容易出现各种问题。
作者回复: 👍是的，得知人善用，得要有合适的流程规范对过程进行管理，还要帮助团队成员成长。
2
舒偌一
2019-03-21
1、技术转管理，首先是有技术，接下来就是业务，技术、业务是基层管理人员的基础，没有这两个，上下怎么沟通？很容易就成为一个协调员，上级领导干预。 2、认知的转变，做技术只是解决单个问题，做管理是团结成员一起解决问题，共同完成团队目标。 3、一起制定制度，明确分工、职责、工作流程、完成标准。最好有一份对应的清单。 4、最重要的是团结成员，围绕共同目标做事，这个是管理风格了，有的是严厉的制度，有的是喝酒唱歌
展开
作者回复: 🙏谢谢补充 “技术和业务是基层管理员的基础”这个说得特别好👍
3

