CTO来分享:致新晋技术管理者,扎实做好项目协作、推进和管理
致新晋的技术管理者
接上一篇文章《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!