本文主要是介绍架构每日一学 14：架构师如何进行可行性探索？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
架构活动中，如果不进行可行性探索可能会导致重大失误，为企业发展带来风险。
可行性探索是架构活动的最后一个节点，在这之后的架构活动就像是离弦之箭，即便发现重大风险也很难再回头了。
互联网公司之间的竞争非常激烈，所以这里的可行性探索还需要足够快。如果你在一个项目中光可行性探索花了两个月的时间，竞争对手可能已经把新的业务模式做起来了，优势已经丧失了。
为什么要进行可行性探索
注意这里称之为“可行性探索”而不是“可行性分析”，原因在于可行性分析是一个非常详尽的活动，严格意义上讲，他不适合互联网这样的快节奏，所以我们使用“可行性探索”来表示一种更快速、更轻量的可行性分析方法。
在可行性探索中，架构师要在最短的时间内发现项目的重大风险，并对风险及时做出响应预案。
可行性探索的过程就是要站在“赞助者”的角度去客观分析可能带来的风险。
什么是风险？
谈到风险，我们会下意识地认为风险是一个贬义词，是对一个项目不利的地方。事实上，风险经常可以作为架构师的筹码，给自己的架构活动换取更多的时间。
比如你想过河，在你面前有一条小桥，但是年久失修，比较危险，远处有一个高架桥比较安全。如果你从小桥过去，相比高架桥会面临更大的风险，但是节约时间；相反，如果我们选择高架桥需要多花半天或一天的时间。
如果业务要求项目在很短的时间内上线，而架构师评估下来具有一定的风险，那么这时架构师这时就可以通过对风险的评估，为自己争取更多的时间。
具体可以从以下几个方面评估：
- 风险有多大？
- 回报是什么？
- 公司的风险承受程度有多大？
- 其他选项的风险和回报是什么？
有了这几个问题的答案，我们就可以进行可行性探索了。
可行性探索前的准备工作
一 调查企业对风险的承受度
不同企业对风险的承受度是不同的，有的企业鼓励员工冒险，而有的企业对于失败的容忍率很低，甚至为零。
假如你在一个冒险容忍度很低的部门里选择冒险，团队中的成员会感受到威胁和压力。相反，如果你在一个鼓励冒险的部门中，却选择不冒险，这就是在拖团队的后腿了。架构师只需要将冒险程度控制在企业的容忍范围内即可，这是选择冒险的上限。
二 调查赞助者对风险的承受度
赞助者对风险的承受度往往很低，往往决定了冒险的下限。因为架构活动的成败，将直接与赞助者的利益挂钩，所以赞助者往往对失败的容忍度很低。
三 锁定领域专家
为了避免架构师单人视角的局限性，还需要寻找一到两个利益无关的领域，专家去询问他们的建议，从而锁定领域内可能出现的重大风险。
四 锁定风险决策的建议者
风险决策的建议者是指，与部门利益关系密切，但与此次架构活动的成败关系不大的相关方。这些人往往视野更加开阔，判断力更强，我们可以寻找四五个这样的人，通过他们的判断和建议，保证此次架构活动的公正、客观和正确。
小结
结合前面的文章《架构每日一学 9：架构师要学会构建或寻找一个友善的环境》、《架构师必读 13：如何精准设定架构目标，确保项目成功？》，我们可以梳理出架构活动的几个关键节点，一是搭建架构环境，二是确立架构目标，三是充分利用公司的资源，帮我们进行可行性探索，来保证决策质量。可行性探索不是让你变得保守，不去冒险，而是秉承着冒险精神去做风险的深度挖掘。
这篇关于架构每日一学 14：架构师如何进行可行性探索？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
