技术负责人招聘(致新晋的技术管理者)-郑州富士康最新招聘信息

致新晋的技术管理者

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

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

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

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

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

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

技术管理者的角色转变

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

常规需求迭代的协作

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

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

图片来源于网络

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

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

技术专项的落地和推进

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

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

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

重大故障的响应和处理

线上故障，不同线下bug。故障主要包括线上正式环境的故障处理，以及付费客户或大客户的工单响应和售后服务支撑。这部分是突发性的、被动处理的、而且情节严重、一旦发生将会产生重大的损失。

如果技术基础弱、系统前期为了追求业务的快速野蛮发展，就会有成长期遇到各种疑难杂症。搞不好，就要“天天救火”，真是的“天天救火”。那阵势，犹如“剪不断，理还乱”。每天都有新的问题暴露出来，而且每次的根源都各有不同。

如果本身缺少监控体系、业务指标，就会“两眼一抹黑”，不行就靠升级服务器配置，或者重启服务器。

提前规划和准备你的系统监控体系和健全日记信息，对于日后发生故障时，将大有裨益。这是对业务研发团队最有建设性的建议和忠告。别等故障频发时，再来着手，就晚了。

代码虽小，影响甚大。

要想系统稳定、平顺、健壮，还是需要从代码和逻辑层面入手把控。如果开发人员使用不正确，例如写了一个死循环，再高配置的服务器、再大的服务器内存、再厉害的数据库和队列，也无济于事。

代码写得不好，每天都会看到数据库慢查询、攻击、越权、超时阻塞、系统卡死、内存打爆、CPU爆满、磁盘占满等问题。甚至也有可能出现150M/s的异常大带宽等毛刺。简直是能刷新工程师的人生观和上限。

150M/s的异常外网出带宽的真实截图

每次处理一个线上故障，都跟侦探破案似的。根据一点点蛛丝马迹，最终成功查获故障的“凶手”。这酸爽，你懂的。

项目集及阶段性的汇总

在YesDev协同工具中，可以通过创建项目集进行宏观的汇总和把控。

创建项目集后，可以自由选择和关联需要的项目。

从项目集，再下沉进入到具体的指定项目，这时的项目，可以是上述的需求迭代项目、也可以是技术专项项目、或故障处理的项目。

根据开发经验总结，对于产品需求的迭代，可以对于同一产品线，按每个月创建一个项目然后规划迭代需求；也可以根据产品的大版本规划一个项目。在每个项目，再整体把控当前项目的需求完成进度、任务开发进度和问题缺陷修复等进度。同时，也要关注项目的最新动态和更新。

继续深入，也可以查看项目的排期表、里程碑、项目燃尽图、附件、敏捷看板等。

概括来讲，基于多年的研发经验，在YesDev，总结归类提供了三大类：工作项、统计图表、和通用模块。基于这三大类、共24个模块，可以自由组合自己团队的项目协作模板，从而匹配DevOps、技术专项、敏捷开发、故障处理、培训等项目的场景协同需要。

日报、周报、月报、项目报告

作为技术管理，日常汇报、总结是必不可少的。下面，稍微略过介绍一下，在研发协同过程中，可以用到哪些汇报的方式和内容。

成员日报：

个人周报：

项目汇报：

各类周报：

测试计划的具体测试报告：

整体宏观的统计数据等，

顶住压力，整体把控，最后看结果

最后，给新晋的技术管理者的寄语就是：希望你能顶住各种压力，时时刻刻做好整体的把控，最后通过你的带领和整体团队的共同努力，交出让大家都满意的答卷。

最后最后，再补充一张宏观的管理规划路线图。

Good Luck!