最近在思考一个问题,在项目需求分析阶段,到底是应该“事无巨细” 还是 “点到为止” 呢?

这个问题源自我最近参与公司其它项目的经历,作为一个“外来者”,按照他们组的规则按部就班的推进需求分析的进度。
我发现的第一个与众不同是他们组开会特别频繁,而我们组正式会议几个月都很难一次,当然我们组存在频繁的小会议(问题参与者们自发组织的临时会谈)。

其实,会议频繁不算是问题,但每个会议必须有效率。我参与的这个组的会议中,经常出现参会者完全没有主题要表达,或者为了找一个文档花费好几分钟。这些是缺乏准备造成的(也可能是会议实在太多,大家都不以为然了~),也和组织会议的负责人在之前没有描述清楚会议主题有关系。这些都可以很轻易的解决~

最大的问题是,会议中沟通时,大家多同一个需求,存在多套叙述语言。但这可是一个运行很久的项目了,竟然还没有“默契的”形成统一的沟通用语。这很难解决,在我们组,在新需求初期,我都会在讨论的初期阶段,时刻关注着大家的沟通用语,一旦发现有“恰到好处”的代名词,我都会反复强调它,并明示所有组员,该需求点以后只允许使用该代名词来表达,不管是在会议中还是在文档里。

最后绕回到我们的本文的主题:到底应该讨论到哪个程度才算合理?

说说我个人的看法吧,我是个比较粗颗粒的人,往往比较在意全局层面的相关问题。前几年“全栈工程师”的概念比较火,我一度以为我之所以有这种思维方式,是因为前后端我都多多少少有所涉猎。但后来我发现也不完全因为如此,尽管全栈会让我的思考可能更全面,但在何时何地把握何种层面的思考,是需要刻意训练的。否则你知道的越多,你就越容易陷入“分析瘫痪”中。

另外一方面,团队会议中必须有人时刻保持对全局问题的敏感性,在负责各自领域的讨论者提出一个方案时,总应该有个人用全局的眼光来进行校验。这个听起来很自然~ 不过人往往都很难面面俱到,不是么?我在做这个角色的时候,就无法同时兼顾细节。例如我不会允许自己过分思考具体方案的细节问题,要尽量的站在方案之外,观察它是如何与其它部分协作的,是否会造成其它部分的困扰和麻烦。

所以我们组讨论的时候,我总是提一些很“笼统”的建议。笼统但绝不模糊,我会反复强调需求中包含的约束,也会提及方案应该避免的一些不好的方面。我会留一个大大的问号给这部分的实际负责人,但我同时会给他定好一个问题边界,我们在会议上多半就只能得到这种“点到为止”的结论。

我有思考过我这种“偷懒”到底源于什么?首先和我的性格有关系,还有就是我发现,开发人员多数(并非全部)都喜欢接受挑战,但这些挑战必须和技术密切相关。这个时候如果开发中所有的枝枝叶叶都在会议中确定了,这个活儿就失去了魅力~ 我认为总是应该留有一些空间给开发人员,再给他增加一些期许的目光和鼓励的对白,一般稍微有上进心的人都会给你交付一份完美的答案。

回到我提到的这个项目上,在会议中我看到项目经理会追着细节不放,不停的连续追问,而开发人员难以掩饰的不耐烦,加上笨拙的沟通技巧,原本十几行代码做的工作需要讲很久很久。。。

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

关注细节的优势在于,对组内新人更友好(另一个问题是真的应该在项目中间加人么?),对项目更保险。最终交付的结果更容易把控。
但这一切都是可以通过code review来弥补的。这好像也是技术管理离不开开发能力的本质原因?

说了这么多,依然都是我的个人观点,我希望得到前辈们的指点,请留下宝贵的建议吧~