技术还是管理？对的选择价值 100 W+

会员服务 ·

技术还是管理？对的选择价值 100 W+

2018 年 1 月 27 日 开源中国 码云Gitee

在 IT 工程师的职业规划上，很多人为选择技术 Or 管理路线而纠结，还有人长久性的“举棋不定”，从程序员的商业价值来说，正确的职业选择至少价值 100万。

程序员应该如何规划自己的职业道路？

技术岗转管理岗会面临哪些问题？

如何充分展现自己的价值？

技术管理者该提前做好哪些准备？

本期进击的程序员由本初网络创始人左华栋老师，为大家免费深入剖析工程师的职业发展路线选择与规划。

嘉宾介绍

左华栋，陕西本初网络科技有限公司创始人，开源项目 Notadd 作者。

大学期间即成立简凡工作室，团队以给学校开发网站为主，在 phpwind9.0发布时，简凡工作室制作了许多插件，成为了当时 phpwind9.0 插件模板最多的第三方开发商。

后创立本初网络，从事于网站建设等相关服务，涉及软件、硬件，对于产品、技术、运营一体化都有非常丰富的经验。

1. 技术还是管理，程序员应该如何规划自己的职业道路？

首先做性格评估——适合做管理吗？

关于这个问题，网上可能已经有上百种答案了，很多都是一些比较有道理的废话，而我想从“管理者应该避免的性格”来谈谈这个问题。

优柔寡断，有选择困难症，朝令夕改的人。

此类型的管理者，不仅让下属摸不着头脑还会对公司管理层的公信力产生质疑。刚刚转型管理者的程序员可能会由于缺乏自信，多多少少会出现这样的情况。

在我们公司初期也遇到了这个问题，凡是涉及全公司的制度和政策，都统一口径通知，先做一段试行，看整体情况，即使要修改，也必须等到下一次全员通知。

不过这点不用过度担心，属于可克服的缺陷，平时的工作中要多注意这些问题。

悲观情绪严重，缺少安全感，凡事总先看到缺点，悲天悯人，总有刁民想害朕的人。

这种情绪问题是比较严重的程序员，往往会给团队带来负面影响，团队更需要一些积极向上的正能量，如果管理层都充满悲观情绪的话，被管理者肯定也不会有太多的积极性。

这个问题比较严重，建议先克服心理因素。

无担当，易动怒，遇事先找个替死鬼的人。

经常责怪下属没有执行力，一心想找人给下属培训打鸡血。可以说，这种很常见也很普遍，有很多中型的企业，也喜欢给员工培训洗脑，但是这种打鸡血行为恰恰是管理者不想承担责任的借口。

这种情况在中型公司比较常见，实际原因来说：一是管理者没有多次强调，二是被管理者利益与公司利益矛盾。

这个问题在初期影响不明显，建议在工作中逐渐克服。有些企业还动不动就搞培训，搞讲座，想通过这种方式提高执行力，实际最需要提高的是管理者本身。

我之前有看到一个说法是：日企的执行力高是因为他们经常把任务重复三遍以上。

注重人情关系，工作生活不分，凭感觉做事，奖惩不明的人。

首先，在工作上尽量撇开人情关系，如果确实难以取舍，建议还是不做管理，否则会导致公司拉帮结派严重，内部腐败等问题。奖惩也好，一定要建立在公司制度上，在此之外需要特批的，也得走流程进行申请，然后不断完善制度。这个问题比较严重，我建议还是能尽量先克服。

我们团队之前也发生过类似情况，觉得相处时间比较久了，不忍心辞退比较负能量的员工，结果最终影响到了核心成员的离职。总的来说，对公，该干什么还是干什么，争执也好，奖惩也罢；对私，该吃饭吃饭，该玩乐玩乐，能准确处理好这种关系十分重要。

我们公司离职的员工有时候也会来一起吃个饭什么的，管理者的心态应该是：反正上辈子又没有仇，哪里来那么多怨。

在我们团队初期由于缺乏统一的统筹规划以及各自过于独立，导致大家一直在做自己认为对企业正确的事情，结果造成了严重的资源浪费。兵熊熊一个，将熊熊一窝也说明了管理者性格的重要性。

职业路线评估——是否必须做管理？

做完性格评估后，接下来，要知道是否必须做管理，或者说走管理的路子。

管理是很多程序员的路线之一，但不是必然路线，管理也不是高高在上享清福，权力越大，责任也越大，比如要求后天上线，而你有十几个程序员苦于修 BUG，这时候你应该怎么办？找外援，加班？外援如何快速熟悉公司项目，加班薪资怎么算？怎么避免不满情绪，如果加班都没做完又怎么办？如果看到这已经焦头烂额了，就重新思考下，是否真的那么想做管理吧。

好的管理不一定有好的技术，但起码要让被管理者信服，尤其是存在程序员鄙视链的情况下，举例来说，比如某公司的商城系统，据说 PHP 全部换为 JAVA，原因是技术总监熟悉 JAVA，觉得管不了 PHPer 。

当然，也有一些喜欢传统的，用FTP 管理代码，导致大家每天要下载5G 左右的代码和文件做同步，经常相互覆盖文件，而且公司不做代码规范。这种情况的话，如果还想对自己技术有所提升，要么自己参与管理，要么还是尽早离职吧。

最终路线评估，我还是希望大家能做个表对比下，看看哪些是可以舍弃，哪些是可以克服的。

|-------好处--------|-----坏处-------|

|--能提升自我--|--人情关系可能不那么融洽了--|

|--能够尝试一些新的技术栈--|--对项目管理没有经验--|

顺便插一句，用FTP 管理代码的那哥们的团队后来集体开了个迅雷会员，来解决下载问题。

2. 技术岗转管理岗会面临哪些问题？

技术选型

技术选型是作为一个技术管理者不得不考虑的问题，除了结合现在公司情况和业务与市场情况，还应该了解人才招聘情况。

我们一开始主要做 web ，后端选用了 PHP ，为了代码质量，用了 Laravel 框架，但是在西安，Laravel 特别难招。随着 vue 的发布，我们公司后端 Laravel 前端 vue ，一定程度上减轻了后端工作量，但 Laravel 招聘问题一直没得到很好的解决，人员流动比较大。

后来随着业务范围的拓展，发现纯 PHP 越来越难以单独胜任一些高并发以及嵌入式的场景，尤其是单页应用盛行的今天，更需要后端提供 API 。这期间也了解了swoole 和 reactphp ，但是相对来说招人就更困难了，培养成本更高。

node.js 招人也十分难，于是最后决定招 java 转node （考虑成本等原因，招的并不是成熟的 java 工程师），为了减少不适应的情况，同时我们也期望有更好的架构，我们选用了 nest.js 框架，这是一个 node 版的 spring，同时也用 typescript 统一了前后端语言，为了更好地适配 typescript ，我们最终选用了 React （下载量使用量多，社区成熟稳定）。

通过这次转型，我们实际开发成本下降了有30-40% ，开发效率提升了20% 以上，同时性能还有大幅度的提升（业务场景下，node.js 异步非阻塞机制表现十分出众），当然不是说 PHP 不好，只是说如果想用一些好的技术和框架，还是应该考虑当地人才市场情况。

有技术选型困惑的倒是可以一起交流交流，只是技术选型这个问题上，不建议盲目追新，要考虑实际情况，当然也不推荐太过于守旧，尝试一些新的技术，对自己以后发展还是有好处的。不用过分纠结于语言的好坏，主要还是看市场需求。

是否适合敏捷开发？

敏捷开发基本上是一个好公司的标配了，尽管如此，我还是不建议一些小团队使用敏捷开发，一方面他对管理要求特别高，尤其是在公司项目管理还没成型的情况下，盲目推崇敏捷开发可能适得其反，最终导致相互推卸责任。另外，团队人员不稳定的情况下，敏捷开发也不适合。当然如果以上问题都不存在的话，那我强烈建议转型为敏捷开发。我们目前是敏捷开发和瀑布流开发混合使用。

另外，不管使用不使用敏捷开发，我都建议使用 git 来做代码管理。不论是 GitHub 还是还是更符合国内使用习惯的码云Gitee 都可以实现，最重要的是：码云创建私有库是免费的，这点比较良心，做个代码“网盘”不错。以我们团队情况来说，主要有三个分支，一是对内开发，二是对外开发（接的一些外包），三是我们开源项目 Notadd ，相当于三个团队，用码云企业版管理和分配任务，以及查看任务统计大大方便了我们。

根据我们的使用经验，码云更适合中小型开发团队，除了能满足基本的代码托管外，还能方便的支撑项目管理和文档协作方面的需求。当然小型团队可以使用个人版本的码云，创建私有库就可以，好东西大家都可以来体验。

如何避免人治？

对事和对人的看法一定要分开，对管理者来说，这是很难能可贵的品质。对事不对人，这点十分重要。关于法治问题，这个我倒是推荐看看《大秦帝国：裂变》关于商鞅变法这段，想对于齐国而言，只有商鞅的法制能够最终得以延续。

讲个典型的人治例子：我之前有个朋友8点去公司，老总8点10分发通知，说是所有人必须8点40之前到，由于他没看手机，然后“迟到”，老总为了立威扣了他200元工资，扣不扣，扣多少都是老总说了算，没有相应制度，于是他选择了离职。

在管理上，存在漏洞是正常的，但是应该正确认识到问题，修改相应的规则，并进行通知，而不是全部特殊处理。

另外，平等并不代表绝对的公正，管理上还应该考虑个人差异。

执行是管理成败的关键。

这里的执行说的是管理者的执行，作为管理者应当对制度进行严格的执行，制度可以宽松，但是执行必须严格。初期一定不要怕麻烦，形成习惯以后就是良性循环了。

即使不是自己去执行，也应该对执行者做深入的考核，保证执行的有效性。

不谈奖惩的制度都是耍流氓，如果违反相应的制度，应该接受怎样的惩罚，这是应该提前定好的，否则后续执行会有很多坑。

3. 如何充分展现自己的价值？

团队协作能力。

作为管理来说，应该培养的是一支团队，而不是某个人才。团队协作能力是一个基础，使用git，制定代码规范，命名要求，环境统一等都是尽可能减少团队成员之间差异的方式。

实际上由于个人能力差异，经常会出现 A 写的代码，B 得费很大劲才能看懂，那这时候就应该考虑每个成员必须在开发过程中应不断完善开发文档和说明了。

还有一类情况特别普遍，尤其是对于一些没有经验的程序员，比如一个小功能，他首先不是到码云 Gitee 或其他平台去搜，而是自己写，等填完各种坑后才发现，网上有大神写好，并且开源的东西了，很多工作都等于白做了，一定要培养搜索的习惯。

当然也不建议什么都搜，我们公司之前也有，搜了以后纠结用哪个好，然后又查了几个小时，公司建立一个常用开源库也是不错的，大家把自己常用到的好的库链接都放上去。

进度把控能力

如果做项目管理不做好进度把控，这会导致在很多公司不受待见。进度是很多开发公司的生命线。

一方面做好时间的评估，项目允许的时间，项目管理安排的时间，由于个人能力差异可能完成的时间，并且预留大把的时间做 BUG 修复工作以及应对可能存在的项目延期。开发者所给的时间经常不靠谱。

过程中要做好按天管理的进度把控，在时间评估上不建议包含周末，而在实际开发调整过程中，可以根据项目情况决定是否要包含晚上和周末（加班）。如果加班比较频繁的话，建议在项目完成后多给开发者休假时间。

紧急补救，一般来说，这时候找外援补救，除非对方经验十分丰富，否则很难做好补救措施。我们也遇到过补救团队跑路的情况。另外一方面也要尽可能跟销售和市场方沟通，尽量平复甲方的情绪，同时可以先上线一部分主要功能。如果这样的情况较多，可以找靠谱的团队长期合作（救火专用）。

不要做过多的进度承诺，尽量预留较为充足的时间，千万不能对项目进度迷之自信。同时保证项目代码的的安全性，项目代码全部以 git 提交为准，既方便了协作防止代码冲突，也能防止一些意外发生，我们是有硬盘损坏的血泪史的。

代码管理是自建系统还是用云平台？实际上，中小型企业自建 gitlab 的成本较高，而且也不能保证代码不被丢失。而云平台会做多份存储与定期备份，即使本地和远端仓库被误删也可恢复，这是自建所无法媲美的。建议有条件的团队购买一些付费版的 Git 托管平台，一般都有协议保障，我们团队 Notadd 项目之所以会使用码云 Gitee，也是为了防止上述悲剧的重演。

4. 技术管理者该提前做好哪些准备？

做好人心会比技术复杂多的充分准备

即使是如此全能如此复杂的 AI 也难以判断人的喜怒哀乐，那么作为管理者要面对的这些问题更加复杂了。举个比较有意思的例子，说是有个皇帝喜欢石头，就派官员去全国各地找漂亮的石头，起初，很多平民也上交一些奇异的石头换取金钱。再到后来，形成了一股挖石头的热潮。最后沦为了一些官员的滥用职权的借口，说你家地底下有好石头，需要把房子扒了，挖石头。

做管理也是一样，很多事情，可能初心是好的，但执行起来却最终变了味，最终的结果就是好心办坏事。

我们也经常遇开发者踢皮球的事，前端甩锅给后端，后端甩锅给前端，也有怕得罪人，自己背锅的情况。权责划分一定要明确，有问题一定要当时提出（比如后端接口没写完），防止踢皮球的现象。