致新晋的技术管理者

接上一篇文章《CTO来分享：给新晋技术管理者的研发协同工具——YesDev》，继续来给新晋的技术管理者分享和讲解如何实实在在做好项目协作、项目推进和项目的管理。

现在看来，依然仿佛存在这样的光景：

在内行的技术人员看来，系统就像一个个“大泥球”、“大泥坑”，跳进去，就会遇到各种各样的坑，俗称：埋坑、踩坑、填坑。新人刚来接触和上手一个旧项目、旧代码、旧系统，95%都会说：“以前的代码写得太烂了，维护不了，得重构”。

在外行人看来，软件开发就像一个黑洞，看不明白也搞不清楚，为什么持续投入了这么多人力、这么多钱和时间，出来的系统软件还这么难用、这么多bug、这么多故障？而且开发效率还这么低，明明改一个文案或改几行代码的事情，非得要给你排期到下星期。你说急人不急人。更让人担忧的，不知道确切的完成时间。研发成本持续高投入，收益却甚微。

而作为新晋的技术管理者，你要思考的问题是：通过你所主导的项目管理和团队管理，以及在你的带领下，你和你的团队，是否能解决和应对软件开发过程中的难题？譬如：需求延期、重大故障、系统维护成本高、开发速度慢等老生常谈的问题。你是否又能让你的领导或你的上级、老板放心或开心把整个团队乃至整个核心业务系统交给你全权负责？

好好思考一下，我们所遇到的软件开发领域的挑战和问题。如果你是技术负责人，你会怎么思考，又会如何开展你的工作？

技术管理者的角色转变

新晋的技术管理者，要思想和觉悟上，首先应当要有角色转变和行动上的变化。

以前，你作为一线技术核心开发人员，只需要把某一件事情或几件事情做好、做到位、做好反馈就可以了。但现如今，作为技术管理者，一定一定要明白和懂得，你现在是对整体负责，而不仅仅再是对你自己负责。如果要排一个优先级，那么就是：首先，对结果负责；其次，对整体负责；最后，才是对你自己负责。

通俗一点，就是，你开始要有全局观。

打个比方，当需要进行开展救援活动时，你不仅要关注现场情况，还要了解当时的天气状况，和受困人数，以及团队的力量等信息。学会站在总指挥室和项目总负责人的角度，开始思考。

图片来源于《乌鲁木齐：雪山救援演练锤炼应急处置能力》

接下来，还要明白，你要开始管人、管事、管项目，除了要安排，还要沟通、协调、记录，此外还要向上汇报和反馈。可能你以前不需要参加会议，不喜欢与人交谈，不擅于当众发表讲话。现在，你都要去适应，去胜任，去习惯，甚至要学会Enjoy这些工作。

站在负责人的角度，俯视整体工作的分类

再进一步具体化，在软件开发领域，在面向业务支撑和产品研发团队，其核心主要的工作可以分为以下三大类。

第一类：常规需求迭代的协作：

产品需求的升级或新功能的开发，以客户需求为导向；

第二类：技术专项的落地和推进：

针对于代码重构、性能优化、数据库/服务器迁移、新技术栈引入使用、底层关键技术突破性研究、架构提升优化等以技术为导向的专项；

第三类：重大故障的响应和处理：

主要包括线上正式环境的故障处理，以及付费客户或大客户的工单响应和售后服务支撑。

最终，归集到项目集，为核心业务的结果负责。下面依次展开分享。

常规需求迭代的协作

做技术，做研发，最常接触的就数新功能和新需求开发和迭代了。

针对需求开发和软件迭代，在行业内已经有成熟和规范和流程，例如敏捷开发、Scrum、瀑布流、DevOps。

图片来源于网络

在YesDev这款协同工具，YesDev为企业研发团队整理和推荐的开发协同流程是：

至于你团队的具体开发流程，则需要结合自身业务特点、产品开发方式、团队的规模、历史情况等进行制定。没有最好的开发流程，只有更合适、更贴切的协作方式。

技术专项的落地和推进

技术专项，是指除了功能性的需求开发以外的事项，通常由技术侧主导和发起，包括但不限于：代码重构、性能优化、数据库/服务器迁移、新技术栈引入使用、底层关键技术突破性研究、架构提升优化等以技术为导向的专项。你也可以围绕DevOps、CI/CD、自动化单元测试、安全漏洞、线上监控、蓝绿发布等进行规划和落地。

例如，结合DevOps和敏捷开发的体系建设和专项推进。

DevOps是为了融合当前主流、经典、成熟的工程思想、理论和体系；敏捷开发是为了能为我所用，为业务所用，为公司带来更高的附加价值。