事无巨细Vs点到为止

这个问题源自我最近参与公司其它项目的经历，作为一个“外来者”，按照他们组的规则按部就班的推进需求分析的进度。
我发现的第一个与众不同是他们组开会特别频繁，而我们组正式会议几个月都很难一次，当然我们组存在频繁的小会议（问题参与者们自发组织的临时会谈）。
其实，会议频繁不算是问题，但每个会议必须有效率。我参与的这个组的会议中，经常出现参会者完全没有主题要表达，或者为了找一个文档花费好几分钟。这些是缺乏准备造成的（也可能是会议实在太多，大家都不以为然了~），也和组织会议的负责人在之前没有描述清楚会议主题有关系。这些都可以很轻易的解决~
最大的问题是，会议中沟通时，大家多同一个需求，存在多套叙述语言。但这可是一个运行很久的项目了，竟然还没有“默契的”形成统一的沟通用语。这很难解决，在我们组，在新需求初期，我都会在讨论的初期阶段，时刻关注着大家的沟通用语，一旦发现有“恰到好处”的代名词，我都会反复强调它，并明示所有组员，该需求点以后只允许使用该代名词来表达，不管是在会议中还是在文档里。
最后绕回到我们的本文的主题：到底应该讨论到哪个程度才算合理？
说说我个人的看法吧，我是个比较粗颗粒的人，往往比较在意全局层面的相关问题。前几年“全栈工程师”的概念比较火，我一度以为我之所以有这种思维方式，是因为前后端我都多多少少有所涉猎。但后来我发现也不完全因为如此，尽管全栈会让我的思考可能更全面，但在何时何地把握何种层面的思考，是需要刻意训练的。否则你知道的越多，你就越容易陷入“分析瘫痪”中。
另外一方面，团队会议中必须有人时刻保持对全局问题的敏感性，在负责各自领域的讨论者提出一个方案时，总应该有个人用全局的眼光来进行校验。这个听起来很自然~ 不过人往往都很难面面俱到，不是么？我在做这个角色的时候，就无法同时兼顾细节。例如我不会允许自己过分思考具体方案的细节问题，要尽量的站在方案之外，观察它是如何与其它部分协作的，是否会造成其它部分的困扰和麻烦。
所以我们组讨论的时候，我总是提一些很“笼统”的建议。笼统但绝不模糊，我会反复强调需求中包含的约束，也会提及方案应该避免的一些不好的方面。我会留一个大大的问号给这部分的实际负责人，但我同时会给他定好一个问题边界，我们在会议上多半就只能得到这种“点到为止”的结论。
我有思考过我这种“偷懒”到底源于什么？首先和我的性格有关系，还有就是我发现，开发人员多数（并非全部）都喜欢接受挑战，但这些挑战必须和技术密切相关。这个时候如果开发中所有的枝枝叶叶都在会议中确定了，这个活儿就失去了魅力~ 我认为总是应该留有一些空间给开发人员，再给他增加一些期许的目光和鼓励的对白，一般稍微有上进心的人都会给你交付一份完美的答案。
回到我提到的这个项目上，在会议中我看到项目经理会追着细节不放，不停的连续追问，而开发人员难以掩饰的不耐烦，加上笨拙的沟通技巧，原本十几行代码做的工作需要讲很久很久。。。

那这表明过度关注细节就一定不好么？
这也是困扰我的原因，如果一种方法绝对的好，那任何关于它的讨论都显得多余不是么？

关注细节的优势在于，对组内新人更友好（另一个问题是真的应该在项目中间加人么？），对项目更保险。最终交付的结果更容易把控。
但这一切都是可以通过code review来弥补的。这好像也是技术管理离不开开发能力的本质原因？
说了这么多，依然都是我的个人观点，我希望得到前辈们的指点，请留下宝贵的建议吧~