如果架构师错了怎么办?


可能在项目中对架构师都有这样的看法——强势,他做所有的技术决策,并对结果负责。然而,有人可能会问一个显而易见的问题:如果架构师出错了,会发生什么?这是否意味着整个项目都面临失败的风险?让整个团队对结果负责,而不是一个人的责任?


当然,如果架构师足够正确,最坏的结果不会出现。这意味着,架构师首先具备以下3种能力:

  1. 分析真实情况;

  2. 收集所有可用的不同意见;

  3. 找到最佳的选择,将个人情绪放在一边。

有多少人真的可以做到这一点呢? 很少。


现实中很多时候可能会滥用权力,变成一个不听任何人,不采纳不同意见,并根据个人感受做出技术决定的架构师。 有多少人遇到过这样的架构师?反正我听过不少。


解决方案是什么?


首先摆脱架构师一个人说了算,让团队决定正确的架构是什么?如果用民主取代一个人说了算,让开发者以某种方式投票,这样会不会避免架构师的错误带来的失败?他们都将对项目负责,当项目失败了,他们都有责任?


看起来似乎没什么问题,但这是错误的。团队责任是团队可能犯下的最可怕的错误。所以不行!没有投票,也没有民主。


那要怎么做呢?


设想一个真实的项目,架构师决定使用MongoDB(NoSQL数据库)来持久保存用户付款。这是一个值得商榷的决定,因为传统上,关系数据库被认为是财务数据更好的选择。但是,我们的架构师是一个比较强势的人,我们没能告诉架构师这个决定是错误的,因为知道提了不同意见也没有用。而且,我们不应该要求架构师说服我们,做出决定。 


我们能做什么?


可以想一下,架构师唯一真正的老板就是需求。架构师可能不会听开发人员、客户以及其他人的意见。需求文档是否提到了有关数据库选择的任何内容?很可能什么都没有,所以架构师做的都是对的。需求说付款必须有,要求系统每秒处理多达一百个付款。那么,问题在哪里?


好吧,我们只是觉得选择MongoDB是个坏主意,这只是直觉。也许我们错了,架构师是对的?


为了使情况更加明确并解决冲突,我们需要修改需求文档。比方说,添加这一行:


每个第三方产品的选择必须基于至少四种替代方案的多因素分析。


一旦此条款获得批准,架构师就必须改进产品文档。必须对MongoDB,PostgreSQL,Oracle和其他一些数据库进行分析。定义一些选择标准,架构师将提供一些数字,以使MongoDB的选择看起来合理。


一旦完成,架构师的意见将变成数字分析,可能有缺陷,但相对容易解决。我们只需要额外的花些时间看看这些数字分析并指出它有什么问题。 发现了缺陷,就必须由架构师以某种方式解决它们。


项目中的风险承受能力越低,我们需要看到架构师做出的决策。如果项目非常重要或者架构师的专业水平值得怀疑,我们需要更多的决策形成文件,并频繁地审查。如果架构师水平很高,并且只是短期不重要项目 ,则可不必这么麻烦让架构师决定。


因此,总结一下,不能指望架构师能够成为解决所有问题的专家。另一方面,不能以民主投票取代架构师。这两种做法都是有问题的,正确的方法是通过定期审查来控制架构师做出的决策的质量。


如果你有类似经历欢迎分享,或有不同的看法留言讨论。


评论