从一次不佳的小组讨论展开

用户头像
sherlockq
关注
发布于: 2020 年 12 月 07 日

有时候,工作生活里会发生一些事,使得人从各种角度思考很久,似乎有所得又未必能得出确定的结论。本篇就是这样过程的产物,故而对读者的价值几何不敢保证。同时,“对写不出出色的作品的忧虑,会阻止写出及格的作品“/“任何有价值的产出过程都是伴随痛苦的” -- 摘自几位同事最近的表述



星期五发生了项目里进行了一场预计外的一个多小时的小组讨论。讨论并没有达成一个决定性的结果,但好在“接受现状,等待更多案例再进行判断”也是一种可接受的结论,所以我称其不佳并不是因为是否最终有行动计划。但是讨论过程的效率,一些讨论方式的逻辑合理性,被讨论主题在经过讨论后依旧不够清晰,加上与会者大多不十分满意,使得我在之后一直在思索这个过程。



先说说这里小组讨论的形式吧,我们组共有7人,1个组长5个程序员1个业务分析员,算是比较标准的组成。任何人都可以发起一个议题,然后在小组聊天里发起,并创建一个日程,一般是在30-60分钟。虽然并不会要求所有人参加,但大多成员还是会加入。发起人默认就是主持人,阐述观点,协调讨论,促成结论达成。根据每个人对于事务的态度和积极性,或多或少会有所发言。最后结束前,必然是都会再问一圈所有人的感想。

这种程序能保证每个人都有机会及习惯发言,但如果没有人主导讨论方向还有控制时间,很容易陷入丢失焦点的问题。在相当长的时间里,有个现象是,很多成员都会对同一个事发表个观点,但是重复性很高,也不接着上一个人继续讨论,而是又展开一个角度,导致讨论非常没有焦点,有为了表达而表达的感觉。我和我同在这里从事市场(Marketing)工作的夫人聊起来,这也是她感同身受的一点。对此部分队员也是有意识到的,会有意识地去收拢,我也会前面人发言时自己做点笔记,轮到自己的时候多少刻意总结或者跟进之前的话题,再继续自己的观点。



上周讨论问题的起因,是现在的组长希望推动一个小的改动(用技术的话说,就是将一个Constructor提取成一个独立的Factory Class),改动需要的时间不会超过1分钟。然而大多成员对此不置可否,而原先的作者也无法被说服。在针对这一个1分钟改动的一小时讨论中,各个成员尝试从各种角度提出自己的想法,并没有明显的站边,但显然谁也没有被说服。虽然就团队规则组长有最终拍板的权力,但好在他并没有行使这个权力,还是愿意尝试各种方式以理服人。就算没有成功,也接受将这个问题悬置起来。最后收尾程序,大家也表达了以后希望限制每个议题的讨论时间,鼓励在非关键的问题上接受试错,避免类似不愉快出现。



现在的组长之前是一家电力公司的架构师(在现公司里我们不鼓励这样的职位,这也是另一个话题),并没有太多顾问的经验,多少有点偏命令式的风格。加入团队后发生过几次摩擦,其它队员包括我也在一对一的时候给他过反馈,能够感觉到他尝试在融合适应,同时保留自己专注结果的优势。小组里也有经验丰富的队员,有时意见相左,气氛一度凝滞过,他最近也说在改进自己工作的方法,比如有意识限制自己给出意见的频次,注意挑出最重要的前三个,看是否能够避免分散话题,并提高意见的重量。

针对类似的团队讨论问题,整个项目的负责人同时也是公司创始人曾提到一个比喻,说每个人头上都有三个帽子,类比一个人的信誉点(Credit),如果在一场讨论中一直在消耗,会减弱发言的重量。



回到这次讨论,事后发现每个组员都在各自思考过如何改进,也在和负责人的一对一沟通里提到过。 我的首要感想是,其它组员应该有意识地在更早时候进行干预,而不是全都陷入在讨论中。由于组长本人是会议的召集人,而另一位又是经常扮演协调的角色,结果其它成员没有意识到这个角色的缺失。这是一个稍加意识将来就能立刻改善的问题。



另外个感想则更为理论化一点,但也让我花费了很多时间思考。在讨论中,组长一度搬出了一个“准则”(Principle,从行业话语来说,就是耳熟能详的Single Responsibility原则),询问了是否大家都同意这个准则,并且隐晦地将同意这个准则与优秀的开发人员等同起来,使得大家一度不知道如何回答。虽然另一个组员提到了一个相反的准则(Less is more,simpler is better),也因为相对应用较弱而没被组长接纳。



我现在的想法是,拿出准则可以提高讨论效率,更快达成共识,因为一个准则是对一个场景和结论的逻辑抽象,如果两方都认同在现在应用这个准备,代表的不仅仅是认同这个准则,更是认同当前场景应用该准则是合适的。另一方面,如果大家意见不同,则不应该纠结于准则本身的正确性,更不应该把它和个人能力捆绑,而因为回归到问题的本质:想要解决的问题是什么,两种方向各自有什么优点和缺点,成本各自几何。一旦高速的路走不通,就应该回退到效率较低但是触及本质的那条路,否则最终会因为迷失在语言的多义性中而进入死胡同。



扩大点说,任何非数理逻辑那样高度抽象,前提假设不存在两义性的原则,都应该用这种方式去处理。自然语言是一种充满陷阱的讨论工具。



以上就是最近工作中的一个缩影。时刻会遇到问题,同时从个人到团队也时刻注重改善;互相间建立信任,保证透明,及早暴露问题。要非要总结点什么,就先丢这几个字吧。



下篇我构思会谈一下从公司到团队里我觉得和过去的工作不一样的一些方面,应该不会想这篇这样有失结构,多谢包涵。

发布于: 2020 年 12 月 07 日阅读数: 20
用户头像

sherlockq

关注

还未添加个人签名 2018.05.13 加入

目前在伦敦工作,分享一手的TDD、敏捷、软件匠艺体悟 https://www.linkedin.com/in/zhiqiang-qiao/ https://zhiqiangqiao.com/

评论

发布
暂无评论
从一次不佳的小组讨论展开