PTT職涯區 / ask-why (知識奧秘)

[請益] 有沒有研究討論流程的學科

看板ask-why (知識奧秘)作者 (不存在的騎士)時間14年前 (2011/06/25 10:49), 編輯推噓12(12推 0噓 45→)
留言57則, 10人參與, 最新討論串1/2 (看更多)
　　在BBS看看了很多討論，感到這個架構對於討論問題還有很多不足， 重複討論沒多久前已經被解決的問題、過度引用新的前提、錯誤地理解 他人論點（並且經常雙方都沒發現）、容易離題、辯論和原問題無關的 細節（口舌之爭）、或者發現離題了但新的問題太有意義以至於不得不 繼續等。我們也看過一些有名的人（著書論述的那種）犯過類似錯誤。 　　那麼我想知道的是：是否有一門研究人如何從討論中獲得知識的學 科（不是原則性的知識論，須細究到流程），或有學者提出過相關的研 究？ -- 　　　 Il Cavaliere Inesistente 　　　http://dejavu.blogdns.org/ 　　騎士是種一旦失去存在的意義，就會崩解消失的東西 　因此他們的一生總在追求著某些事物，以維持自己的存在 如果有了存在的理由，即使是一副空的鎧甲，也可以成為騎士 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 112.104.79.103
推
06/25 10:57, , 1F
科學哲學? 邏輯? 知識論?
06/25 10:57, 1F
→
06/25 11:05, , 2F
那範疇太大了，我要找特化的在執行面上有幫助的東西。
06/25 11:05, 2F
推
06/25 11:57, , 3F
TQC 全面品質管控，研究know how？
06/25 11:57, 3F
→
06/25 11:58, , 4F
田口試研究方法？研究數種變數控制？
06/25 11:58, 4F
→
06/25 11:59, , 5F
你的問題太過空泛...研究哪一種學問，要細究到什麼程度
06/25 11:59, 5F
→
06/25 12:16, , 6F
我問的是「討論」或「溝通」，和你想的方向不太一樣。
06/25 12:16, 6F
→
06/25 12:18, , 7F
我要知道在多人溝通的環境下，如何有效讓一個或多個主
06/25 12:18, 7F
→
06/25 12:18, , 8F
題往對解決有助益的方向前進。
06/25 12:18, 8F
推
06/25 12:22, , 9F
在Ptt？....哈哈哈，天曉得，至少我不曉得
06/25 12:22, 9F
推
06/25 12:25, , 10F
有心裡學版，大概可以問到一些學術的訊息
06/25 12:25, 10F
推
06/25 15:08, , 11F
說不定這個問題等一下講一講就跑題了 xD
06/25 15:08, 11F
推
06/25 15:50, , 12F
只有在書局看過一些相關主題的書~比如有一本講圖像的好處，
06/25 15:50, 12F
→
06/25 15:50, , 13F
裡面講會議進行(多人討論)的流程還算詳細~
06/25 15:50, 13F
→
06/25 16:04, , 14F
關於第一段的問題,我覺得:
06/25 16:04, 14F
→
06/25 16:05, , 15F
.缺少維持討論焦點的主持
06/25 16:05, 15F
→
06/25 16:05, , 16F
.議題持續時間長
06/25 16:05, 16F
→
06/25 16:06, , 17F
.任何人可隨時參與議題
06/25 16:06, 17F
→
06/25 16:10, , 18F
印象中管理學某些知識管理在討論類似的東西...
06/25 16:10, 18F
→
06/25 16:15, , 19F
StaticVortex有講到一些要素。那我目前是在考慮用超文
06/25 16:15, 19F
→
06/25 16:16, , 20F
本的架構設計出一套系統來管理各種類型的議題討論，即
06/25 16:16, 20F
→
06/25 16:17, , 21F
使討論變得冗長也比較能夠表現出關聯性。舉例來說，我
06/25 16:17, 21F
→
06/25 16:18, , 22F
們可以把每個議題看成一個node，它們可能會有child和
06/25 16:18, 22F
→
06/25 16:19, , 23F
parent，可能是網狀的，可能會往不同方向延伸，每個
06/25 16:19, 23F
→
06/25 16:19, , 24F
node可能處於不同狀態，例如沒有共識、採用沒有共識的
06/25 16:19, 24F
→
06/25 16:22, , 25F
前提等，這些關係表現在一張map上。當然怎麼畫這張map
06/25 16:22, 25F
→
06/25 16:22, , 26F
會是很大的問題（master很難找...）。
06/25 16:22, 26F
→
06/25 16:24, , 27F
這問題其實不是網路時代開始才有，只是在更久以前我們
06/25 16:24, 27F
→
06/25 16:26, , 28F
要參與夠深入的討論難度較高，所以很少人發現這（維根
06/25 16:26, 28F
→
06/25 16:26, , 29F
斯坦抱怨過的）問題。
06/25 16:26, 29F
推
06/25 16:33, , 30F
如果一個新入要加入議題,選擇了一個node切入,
06/25 16:33, 30F
→
06/25 16:34, , 31F
那麼他要在這片討論網上爬多少才能發言
06/25 16:34, 31F
→
06/25 16:34, , 32F
而不擔心論點重複?
06/25 16:34, 32F
推
06/25 16:37, , 33F
一個node什麼時候會生出child?
06/25 16:37, 33F
→
06/25 16:38, , 34F
我是不是搞錯你的意思?
06/25 16:38, 34F
→
06/25 16:45, , 35F
不管爬多少才發言，至少比平列式的討論串清楚很多。我
06/25 16:45, 35F
→
06/25 16:47, , 36F
沒有考慮要怎麼處理岔題者，或許在不影響原議題又不構
06/25 16:47, 36F
→
06/25 16:48, , 37F
成新議題的狀況下他的發言仍然會在原本的節點下，甚至
06/25 16:48, 37F
→
06/25 16:49, , 38F
某程度上也可以閒聊（看社群容許的程度）。至於怎麼去
06/25 16:49, 38F
→
06/25 16:49, , 39F
分開node我還不確定，最主要的問題在於它可能不是一個
06/25 16:49, 39F
→
06/25 16:50, , 40F
在沒有足夠知識水準和中立的管理者時可以做到的事。
06/25 16:50, 40F
→
06/25 16:55, , 41F
人性可以維持中立的能力有限，所以應該要有一個對管理
06/25 16:55, 41F
→
06/25 16:55, , 42F
者中立性依賴性盡可能低的機制。
06/25 16:55, 42F
→
06/25 16:59, , 43F
這只是個初步的構想，也可能有的地方不切實際，所以想
06/25 16:59, 43F
→
06/25 17:00, , 44F
找看看相關領域的理論。
06/25 17:00, 44F
推
06/25 18:50, , 45F
這樣想如何? :
06/25 18:50, 45F
→
06/25 18:50, , 46F
如果希望能夠顯示一個node/議題處於何種狀態
06/25 18:50, 46F
→
06/25 18:51, , 47F
(已有結論/沒有共識...),似乎不得不依賴管理者去決定
06/25 18:51, 47F
→
06/25 18:51, , 48F
,因為,不是所有參與者都會留到最後.
06/25 18:51, 48F
→
06/25 18:52, , 49F
另外,離題可分可與不可明確找到切割點,
06/25 18:52, 49F
→
06/25 18:52, , 50F
但無論哪種情形,總會有個發文者發現自己跑題了,
06/25 18:52, 50F
→
06/25 18:54, , 51F
換句話說,那時/篇起再屬衍生討論即可吧
06/25 18:54, 51F
→
06/25 18:59, , 52F
當然是可以的，我只是在找比較有效率的方式。此外也有
06/25 18:59, 52F
→
06/25 19:00, , 53F
討論在通往正確的方向之前就變得無法挽救的情形。
06/25 19:00, 53F
推
06/26 00:48, , 54F
公司裡頭的研發部門不是這樣系統的討論嗎?
06/26 00:48, 54F
→
06/26 19:01, , 55F
我朝管理學和團隊研發相關的文件找找看
06/26 19:01, 55F
推
06/27 06:06, , 56F
學科史
06/27 06:06, 56F
推
06/28 23:57, , 57F
我想到的是辯論賽里的主持人或叫裁判，歸納總結成為習慣
06/28 23:57, 57F
‣ 更多 hermitwhite 的文章
文章代碼(AID): #1E1KpCl- (ask-why)
ask-why 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 hermitwhite 的文章
文章代碼(AID): #1E1KpCl- (ask-why)