在系统的生命周期内，架构问题的发现主要有两种，一种为主动发现，一种为被动发现。一般在团队中成长起来的高阶工程师，对团队的技术及业务都会有一定的了解，对现有的技术架构存在的问题也会有着一定的了解，结合业务的需要及将来的趋势，主动的提出问题，并解决问题是架构的持续优化之道。大部分研发人员不愿主动提出问题，主要的原因有一个就是惧怕冲突，如果这个问题自己能够做到很客观地去评估和针对具体的事情去解决，这件事情就不会与他人有太大的冲突，其实这个问题它本来就存在，只是被提了出来，为了目标想让这件事变的更好。事与事之间的冲突是存在的，一个团队，资源用在什么地方，取决于资源投入的回报率，包括中短期和长期的影响，而不是人与人的冲突。
主动发现问题主要有以下几种方式
- 以相关者的视角看现状：事情如果与自己不相关，就很难发自内心的去主动思考，很难在闲暇的时间去投入额外的精力去琢磨这件事。如果你希望持续的有效的发现问题，至少应该按照这个领域的平均水平来看，投入时间和精力。打个比方，在某个场景或系统存在个问题，你要么投入精力，使用正确的方法，一点一点的把流程弄清楚，发现问题点；要么你有超出常人的思考能力或经验，能帮助你在有限的时间内高质高效的发现问题。一件事与自己有关，要么来自内心的兴趣，要么与自己有直接或间接的关系。如果事情不相关，自然对其关注不足，即使机会真的存在，也会插肩而过。一个人的精力有限，关注的事项也需要聚焦，自己也需要确定关注的方向。
- 以发展的视角看现状：发展是最大的外因，并且是可干预手段较少的外因，确定了相关因素，以发展的眼光去发现问题。一些事情在现阶段它已经到天花板，但随着技术和相关产业的发展，这件事情他会变得越来越好，也会因为外界的变化，现状较优的方案也会成为限制发展的瓶颈。架构优化的研发不同于功能迭代的研发，需要提前的准备，等待业务及功能层迫切需要时，再进行架构的优化，这时的过程就会因为不同层页的述求而改变。
- 以用户的视角看现状：产品上线最终还是交付给用户去使用，为用户提供服务，总结来说就是我们所做的事情都是服务于用户，每一个用户都是多重需求的载体，那同样的一个功能点，因为他的设计流程、体验和效率都会影响用户是否去使用。帮助用户解决具体的问题，就是为用户提供的价值。同时在团队中，协同的小伙伴，直属或间接的领导，都可能是用户，站在他们的角度，同样也会到到当前团队，业务所存在的问题，因为视角不同，发现就有不同。
- 以全局的视角看现状：大部分工程师把接收任务有任务完成，算是完成本职工作。而当你换个视角，在接收需求时，了解背后的原因；在实现的过程有不同的实现方案对比；在交付的过程，关注交付出去的效果，长期的影响等等，这些会发现潜在的问题。一件事的完成的定义有很多，因为视角不同，理解也不同。与具体的事情产生关联，而不是与某个任务点关联，这样可以以更全面的视角来看现状，发现事项的背后原因，过程中的差距，结果的影响。
- 以特定的视角看现状：产品中的业务点都会有一个关键的路径，按照这个路径用户可以使用到该业务的必要能力，这个必要的能力一般就是该业务中的通用流程。在这个通用流程中，相关因素的变化会对业务的结果产生影响，这些因素就是特定的场景，也是流程的一个分支。比如数据通讯中网络信号变差了，数据传输失败，如何优化。特定视角相当于在什么状态下，在什么样的背景下，什么样的人群在使用产品时会遇到什么样的问题，这个场景分支下系统能力应该如何构建，如何运行，基于现有的流程机制是否存在一些可以优化。
- 以审批的视角看问题：审批的视角相当于换个视角来看自己得到的问题的结论是否逻辑正确，相当于自己对于问题的总结，自己给自己作一下检查，带着疑问来栓查，确定相关的因素考虑的是否全面，自己检查自己给出的问题分析的结论，过程中产生的新问题也进行补充，哪些还有遗漏，哪些描述的不够清晰准确，当把这些不确定的因素弄清楚，把缺少的环节给补上，整体问题就变得更加清晰可信，原本一个问题点逐渐发现背后相关的因果关系
