架构师的取舍不是一个艺术，而是一个基于商业和技术环境的理性的思考决策。
在独立性假设之下，任务分配是个局部优化的过程，所以不需要在全局上做优化。在独立性假设之下，真正导致失败的正是你的最软肋，也就是架构活动中成功概率最低的强依赖。这是架构师最重要的关注点，而不是大家都在注意的光环点。
一旦任务边界确认，那么就必须迅速锁定所有必保需求相关的资源。除了研发人员外，还包括业务、产品、研发、流量入口、发布窗口，甚至营销资金池。
项目的成功概率跟参与者的意愿度和投入度的关系更大一些，跟这个人的能力关系略小一些。
需要注意的是，在实际执行的过程中，你往往会漏算，也会碰到突发事件，比如需求方会更改他们的需求。那么在这个过程中，你还需要不断迭代任务分解，尽量把用例从粗到细做成多层分解。一来，你会及早发现更多细节和不自洽的部分；二来，你跟锁定的核心研发人员也能较快地建立信任，让他们尽早参与到需求确认中来， 从而在减少风险的同时增加项目的成功概率。
此文章为5月Day28学习笔记，内容来源于极客时间《郭东白的架构课》
