当管理者需要做架构决策时，就意味着至少有两个、三个甚至更多架构方案摆在面前，各有利弊，需要高层协助决策。在做顶层架构设计时，我们可建设一套构决策流程，如下：
1、当事人发起架构决策申请；
2、由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
3、在产研中心部门内，或联合 CTO 办公室，完成架构评审；
4、将结果发还至当事人征询意见；
5、由当事人判断是否仍有疑虑，需要进行架构仲裁；
6、若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
过程中可能涉及的参与人包括：产品负责人、技术负责人、架构师团队、架构负责人、CTO 办公室负责人等。如果是部门内协调解决，则 CTO 办公室不参与评审；如果评审后仍有分歧，则 CTO 办公室连同其他负责人一起介入架构仲裁，快速解决问题。
在管理小团队时，我可能不会推行以上决策流程，因为我的精力足够覆盖团队每一次重要决策；但对于大型企业来说，上述制度就开始变得非常重要。
我们也要认识到，用体系化的解决方案解决组织问题，是正确的认知。但体系化的解决方案一旦在实际工作中开始落地，也非常容易“变形”。在上述决策流程里，最困难的不是架构评审和架构仲裁，而是向下推进的动作和速度。
image.png
这就要求决策者具备第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。
网友评论