您现在的位置是:首页 >技术教程 >架构活动中评估需求的五个关注点网站首页技术教程
架构活动中评估需求的五个关注点
从架构活动的整体目标出发,确认需求存在的必要性。很多时候,尤其是大的项目,需求方经常会夹带私货。虽然他们并没有什么恶意,但是这些附加的需求不仅会消耗研发资源,还会增加项目复杂度和规划难度。而最坏的情况,就是附加需求会引入风险,导致整个项目的失败。
作为架构师,你需要准确区分最小必要的需求和无关紧要的需求。只有那些与项目目标形成因果关系的强依赖需求,才是属于架构活动的需求。
这个梳理过程,之所以要放在问题域和执行域划分之后,是因为需求属于问题域的范畴,而需求的执行则属于执行域的范畴。如果没有领域划分,你就需要自行砍掉附加需求。真要到这种情况,估计你这个架构师很快就混不下去了。
砍需求是个非常得罪人的事情。你做这件事情必须要有个同盟,也就是与需求对应的、问题域映射到执行域的负责人。因为在砍掉不必要的需求上,你们两个人的利益是一致的。你为了整个架构活动的成功,他则是为了控制自己领域的风险。你可以站出来表达比较客观的立场,而他则可以帮助你证实这个立场的合理性。
这个过程与确认目标的过程类似,你的关注点应该放在如下五个方面。
1、需求的必要性
这个需求有必要吗?与整体目标是因果关系吗?无论这个需求的价值有多大,只要它不是架构活动的必要条件,就应该分开考虑,最好完全隔离在架构活动之外。架构规划最忌好大喜功。
2、需求的正确性
需求是否和架构目标相匹配?想要得到赞助者所期望的商业价值,那你这个需求目标的正确数量级应该是多少?如果一个需求的预期目标,比赞助者所需要的值还要小一个数量级,说明这个目标是不正确的。
事实上,需求不正确的情况在架构活动中频繁发生。表面上看,可能是执行的队友不给力。但更真实的原因是你这个架构师不给力,没有及早发现规划的软肋。
3、需求合理性
在当前交付时间的约束下,需求的交付时间和质量要求是否合理? 是否会出现研发团队动作和设计完全变形的情况?
4、需求的可达性
当前的时间要求和资源投入,能产出质量上可以接受的实施方案吗?实施方案是否高于质量底线?如果某个需求需要多个团队协同,那么我们能留出足够的时间,让团队处理集成中出现的问题吗?
5、需求的承接方
这个需求有且仅有一个团队承接吗?是他们应该承接的吗?他们愿意吗?能力够吗?有研发带宽吗?
一个架构活动中最终要承接的需求,在这五个问题的答案上必须是肯定的。而这个梳理需求的过程,其实也是执行风险的梳理过程。完成这个梳理过程后,你应该对需求与架构目标之间的因果联系有了信心。那么接下来,我们就需要形成一张完整的映射关系表。
此文章为5月Day16 学习笔记,内容来源于极客时间《郭东白的架构课》,推荐该课程。