- Published on
做技术规划的一些思考与总结
- Authors
- Name
- noodles
- 每个人的花期不同,不必在乎别人比你提前拥有
写这个主题是比较忐忑的,自己有一段时间会规划小组内下个阶段的工作目标,现在看当时做的阶段目标其实谈不上技术规划,本文主要结合自身的一些案例总结做技术规划上的一些思考。


自身案例分析
在做下个阶段目标的时候经常会有如下的一些疑问:
- 下个阶段做什么(来源)
- 怎么做(过程)
- 完成的总结 在反思自己之前的制定目标的时候有以下的问题:
- 多数在关注1阶段而弱化了2,3阶段的思考,这样会导致在下一次做规划的时候还是很挣扎跳不出这个圈。
- 没有一个完整的全局视角 这个导致我的一个疑问是业务侧做这个为啥,看着很分散
- 没有一个长期的视角,导致阶段性目标不明确
下个阶段做什么(来源)
在这个阶段我的思路是关注业务侧的规划文档,但是在看业务侧的文档会存在以下的"问题":
- 某些目标比较泛并不能准确的落实到技术目标上 比如收入增加XXX
- 可以收集到下个阶段的业务目标比如需求A,需求B,需求C,但是A,B,C有可能之间关联性不大,当然这可能跟当前的业务现状有关 虽然通过看业务侧文档可以整理出下个阶段的业务目标,但是每次都感觉没有所谓的抓手,有种隔靴搔痒的感觉,其实从现在来看之前的我,可以看出很多思考上不足的点,才导致每次都很痛苦的想下个阶段要做啥。 在思考上可以有两个思路:
- 从上往下视角 从全局视角看不同模块的关系,建立联系和目标
- 从下往上视角 为什么会有这样的关系,基于已有的关系是否会衍生出新的关系,在新的模块上能做什么
下个阶段业务目标
在梳理业务目标的时候可以从以下几点考虑:
- 熟悉业务的现状 熟悉业务现状才能有目的性的查看业务侧的规划来反推出更多的思路来推动业务目标,比如
- 后续会发力营销但是现有的营销页面并不支持配置化那是否可以尝试推动业务侧一起建立配置平台
- 业务侧要对存量的业务有一系列的优化,存量的业务还是老旧的技术栈,那么提前对技术栈进行迁移和统一
- 多与业务侧沟通,建立正向的连接 可以跟业务侧一起建立双向的规划分享,这样互相都比较了解对方做事的思路,团队每人也更有全局的意识
- 数据思维 关注产品数据,业务数据促进对业务的反思,可以养成一个思维习惯就是产品的数据怎么能映射到我当前开发的具体业务上
下个阶段技术目标
在梳理技术目标可以从以下几点考虑:
- 流程优化 梳理业务开发的流程针对性解决,比如:
- 规范 技术栈统一,代码规范,开发上线流程,Code Review(思考中,如何建立有效的Code Review)
- 质量 性能,监控
- 效率 通过工具、库来实现提效,已有业务的抽象组合
- 了解团队成员能力和诉求 可以针对不同阶段的团队成员制定不同的规划,比如工作年限相对短的可以多从一些复杂的业务中成长,年限久的赋予更多的自由度,实现自治
- 技术储备(分享输出等) 技术储备可以为团队输入新的血液,分享和输出可以建立团队的整体意识和对外的口碑
怎么做(过程)
- 里程碑 每个目标阶段要有里程碑,比如做页面性能监控:
- 已有业务接入性能监控
- 主要业务首屏优化达到XXX
- 性能优化总结,推动上下游进行优化,新技术探索
- 可调整 在具体实现上因为优先级或者当前目标实现的结果不理想及时调整当前或者下个阶段目标
- 多阶段完成 一个大的目标可以拆分成多个子目标在规划的多个阶段落实,需要建立多个目标之间的关系,保证规划的整体性
完成的总结
这个阶段可以结合上面的两个阶段来看:
- 完成了哪些业务目标,技术目标,产生了哪些收益
- 过程中产生了哪些问题,是否在下个阶段可以进行优化和避免(下个阶段目标)
- 下个阶段目标调整