被同事嘲笑说技术方案没深度?
这里是Z哥的个人公众号
每周五11:45 按时送达
当然了,也会时不时加个餐~
我的第「194」篇原创敬上
需求分析
方案设计
方案落地规划
方案总结
安全性问题:被劫持、被逆向、被抓包等;
兼容性问题:在不同设备上运行可能存在的兼容性风险;
性能问题:内存泄漏、卡顿、高CPU占用等可能导致整机流畅度和功耗等问题;
合规问题:技术上可能存在的法律风险,比如使用第三方开源库等。
里程碑的划分。划分的颗粒度尽量小一些,以小步快跑的方式及时交付,这样遇到问题能快速调整,降低风险。使得整个落地的过程平滑、可控。(像我这种偏理想化的人,会对里程碑的时间节点预留20%~50%的弹性空间,以免被自己的乐观给坑了~)
验收指标的确定。整个系统设计后是否符合预期,是需要有一些指标来度量的。否则没有人知道你设计的技术方案到底咋样。不小心在别人眼中沦为ppt架构师。
这个场景中存在的主要问题有哪些?
这个技术方案能解决其中的哪些问题,以及解决到什么程度?
实施过程中存在哪些风险?有何预案?
整个项目的投入情况如何?
需求分析
方案设计
方案落地规划
方案总结
防止过度设计
争取尽可能多的设计时间
避免以技术先入为主来设计
推荐阅读:
原创不易,如果你觉得这篇文章还不错,就「点赞」或者「在看」一下吧,鼓励我的创作 :)
也可以分享我的公众号名片给有需要的朋友们。
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」
评论