<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Culture on Tarragon</title><link>https://tarrragon.github.io/blog/tags/culture/</link><description>Recent content in Culture on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Tue, 18 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/culture/index.xml" rel="self" type="application/rss+xml"/><item><title>組織文化與心理安全感</title><link>https://tarrragon.github.io/blog/books/software-management/topics/culture-safety/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/culture-safety/</guid><description>&lt;p>這個主題處理一件其他主題都預設成立的前提：組織回報的資訊大致反映實情。當這個前提失效，指標會漂亮、檢討會順利、承諾會準時給出——所有訊號都正常，只有結果不對。這使得它同時是其他主題的地基與失效模式，也使得它的問題最難自我診斷：沉默的組織裡沒有人會回報「我們正在沉默」。&lt;/p>
&lt;p>這個主題的書大多來自軟體業以外——組織行為學、教育學、管理心理學。這反映的是軟體業自己的書幾乎不處理恐懼與防衛，而這些領域已經累積了三十年以上的實證研究，並非刻意的取材偏好。&lt;/p>
&lt;h2 id="起點是-the-fearless-organization">起點是 The Fearless Organization&lt;/h2>
&lt;p>Amy Edmondson 的《The Fearless Organization》從現象一路寫到操作框架，中間解釋機制的那一段沒有跳過，證據規模也是本篇最大的一本。概念本身的整理在 &lt;a href="https://tarrragon.github.io/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感&lt;/a>，這裡處理的是要不要讀這本書。起點是一個反直覺的研究結果：她研究醫院團隊時預期表現好的團隊犯錯較少，資料卻顯示表現好的團隊回報的錯誤更多。追下去才發現差別出在回報率這一層，犯錯率其實相當——好團隊敢講。心理安全感這個概念與後續三十年的研究從這裡長出來。&lt;/p>
&lt;p>書的操作價值在於把心理安全感從一種氛圍變成可以做的事。框架有三步：把工作定調成學習問題而非執行問題、承認自己會犯錯、主動示範提問。每一步都有語言範例與失敗案例，包括領導者宣稱歡迎壞消息但實際反應相反時會發生什麼。&lt;/p>
&lt;p>需要先知道的邊界是心理安全感並非降低標準。書中把心理安全感與績效標準當成兩個獨立的軸，並指出兩者都高才是學習區、安全感高而標準低是舒適區。這個區分在導入時最容易被誤讀成「對人要溫和」。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是大規模實證加上跨組織案例，強度足以支持組織層級的改變。時效上，書中案例的產業背景橫跨醫療、航空、製造與科技業；心理安全感與績效標準兩軸的論證建立在人際風險的感知上，不依賴工作場所的形式。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，書中的介入手段——把工作定調成學習問題、當場承認自己會犯錯、主動示範提問——多數發生在同步的面對面場合，靠的是別人看得見領導者的即時反應。非同步為主的團隊要先找到對應的載體（公開的決策紀錄、留在文件上的提問、對壞消息的第一則回覆），那個轉換書裡沒有給，換算的方向見 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>。讀得出價值的前提幾乎沒有，任何位置都讀得出東西——只對自己產出負責的人讀它，讀出來的是「原來我不敢講不是我的問題」；帶人的人讀它，學到的是自己做了哪些動作，團隊才不再把壞消息講上來。&lt;/p>
&lt;p>同作者的另外兩本各補一個面向，與這本承擔同一個角色而非獨立選項。《Teaming》處理跨團隊、跨專業的臨時協作怎麼學習，適合矩陣式組織或跨部門專案多的環境，目前無中譯本。《Right Kind of Wrong》把失敗分成簡單失敗、複雜失敗、智慧型失敗三類，並主張只有第三類值得鼓勵——這對把「快速失敗」當成免責聲明的團隊是直接的校正。兩本的證據來源與起點書同一組（大規模實證加跨組織案例），因此不另外判定；處境上，《Teaming》預設協作對象會換人，《Right Kind of Wrong》不預設任何組織形態。讀得出價值的前提是先讀過起點書那本——它們補的是面向，不是入口。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Fearless-Organization-Psychological-Workplace-Innovation/dp/1119477247">Amazon（The Fearless Organization）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010952358">博客來（心理安全感的力量：別讓沉默扼殺了你和團隊的未來）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Teaming-Organizations-Innovate-Compete-Knowledge/dp/078797093X">Amazon（Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Right-Kind-Wrong-Science-Failing/dp/1982195061">Amazon（Right Kind of Wrong: The Science of Failing Well）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010985600">博客來（正確犯錯：哈佛學者揭開成長心態的關鍵）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想知道為什麼改善措施總是失效時讀-argyris">想知道為什麼改善措施總是失效時讀 Argyris&lt;/h2>
&lt;p>Chris Argyris 的研究方法是逐字記錄組織裡的真實對話再逐句分析，因此是這個主題裡證據粒度最細的一位。貢獻集中在兩組概念。第一組是信奉理論與使用理論的落差：一個人宣稱相信的原則，與他的行為顯示他實際依循的原則經常不同，而本人通常看不見這個落差。第二組是組織防衛慣例：組織會發展出一套機制迴避尷尬與威脅，接著把「這套機制存在」本身也變成不可討論的話題，於是防衛無法被檢討。&lt;/p>
&lt;p>這組概念解釋了為什麼許多文化改善措施會失效——措施本身成為新的表演場合，而指出「這是表演」變成新的不可討論話題。Edmondson 描述現象並給出做法，Argyris 解釋做法為什麼會被組織消化掉。&lt;/p>
&lt;p>那篇 HBR 文章〈Teaching Smart People How to Learn〉是最經濟的入口，十幾頁，主張聰明人特別不擅長學習——因為他們很少失敗、沒有練習過面對失敗，一旦失敗就把責任外推。這個論點描述的處境在高學歷、高能力的工程團隊上有明確對應。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗，形式特別的地方在方法：長期的組織介入研究加上逐字對話分析，因此細節極具體，但樣本集中在少數顧問公司與大型企業。時效上，案例場景是 1980 年代的管理顧問與董事會，職稱與會議形式已經不同；信奉理論與使用理論的落差建立在人對自我形象的維護上，不依賴那個場景。文字的概念密度高、案例冗長，《Overcoming Organizational Defenses》是書的形式，但多數人從那篇文章得到的已經接近全書。兩者目前都沒有中譯本。讀得出價值的前提是：親身推動過一次無疾而終的改善——沒有這個對照時，防衛慣例會讀成對組織的譏諷。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://hbr.org/1991/05/teaching-smart-people-how-to-learn">HBR（Teaching Smart People How to Learn）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Overcoming-Organizational-Defenses-Facilitating-Learning/dp/0205123384">Amazon（Overcoming Organizational Defenses: Facilitating Organizational Learning）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="程式碼審查滑向人身攻擊的起源在溫伯格-1971-年的the-psychology-of-computer-programming">程式碼審查滑向人身攻擊的起源在溫伯格 1971 年的《The Psychology of Computer Programming》&lt;/h2>
&lt;p>這本書是最早把寫程式當成人類行為來研究的著作。書中的無私程式設計（egoless programming）——把程式碼與自我認同分開，才能坦然接受別人檢視——是今天 code review 文化的思想源頭。&lt;/p>
&lt;p>現在讀它的價值集中在觀念層。25 週年紀念版的做法是保留原文不動、只在旁邊加註解評論自己當年錯在哪——作者認為自己的錯誤是讀者最能學到東西的部分。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 IBM 與 NASA 水星計畫的現場觀察）加上早期的受控實驗，樣本小、方法以現在的標準看相當鬆散。時效上，技術背景（主機、打卡、批次作業）已經完全不同，涉及工作流程的章節無法直接套用；程式設計師如何看待自己的產出、審查為什麼會滑向人身攻擊這兩條論證建立在自我認同與產出的連結上，不依賴技術形式。收過一次讓自己不舒服的 code review，是讀它的前提。繁體中文版目前未見，簡體中文版有《程序开发心理学》等譯名。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420">Amazon（The Psychology of Computer Programming: Silver Anniversary Edition）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這個主題的三本按解釋深度排：現象與操作框架（Edmondson）、機制解釋（Argyris）、軟體業內部的起源（溫伯格 1971）。三者處理沉默的不同層次，任何一本都不能替代另外兩本。&lt;/p>
&lt;p>企業文化的書是商管書市最擁擠的區塊，多數落在兩個位置：宣稱某家公司文化很成功的個案敘事，以及把文化拆成價值觀清單的操作手冊。前者無法回答「這在我的組織也成立嗎」，後者跳過了價值觀為什麼會被組織消化掉這一層——要區分，看它處不處理「宣告的價值觀與實際行為不同」這個落差，沒處理的停在第一層。&lt;/p>
&lt;p>Google 的 Project Aristotle 常被拿來當心理安全感的佐證，它的一手資料是公開文件而非書籍，因此不列進書單。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>理解機制之後，落到單次對話的執行走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>——那裡處理的是主管盯著人問「到底行不行」的那三十秒。&lt;/p>
&lt;p>沉默在事故現場的具體形式（明知有異狀卻沒有升級）走 &lt;a href="../incident-blame/">事故、歸因與無指責檢討&lt;/a>。沉默在承諾現場的具體形式（明知做不完還是點頭）走 &lt;a href="../estimation-decision/">估算、承諾與決策偏誤&lt;/a>。&lt;/p>
&lt;p>人留不留得住是另一組問題，走 &lt;a href="../retention-motivation/">留任、動機與工作環境&lt;/a>。&lt;/p>
&lt;p>安全感夠了而討論仍然收斂不了，缺的是流程而非氣氛，走 &lt;a href="../meeting-facilitation/">會議引導與群體決策&lt;/a>。兩者的先後不能顛倒——講真話會被記上一筆時，再好的會議格式也只會收到安全的答案。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理一件其他主題都預設成立的前提：組織回報的資訊大致反映實情。當這個前提失效，指標會漂亮、檢討會順利、承諾會準時給出——所有訊號都正常，只有結果不對。這使得它同時是其他主題的地基與失效模式，也使得它的問題最難自我診斷：沉默的組織裡沒有人會回報「我們正在沉默」。</p>
<p>這個主題的書大多來自軟體業以外——組織行為學、教育學、管理心理學。這反映的是軟體業自己的書幾乎不處理恐懼與防衛，而這些領域已經累積了三十年以上的實證研究，並非刻意的取材偏好。</p>
<h2 id="起點是-the-fearless-organization">起點是 The Fearless Organization</h2>
<p>Amy Edmondson 的《The Fearless Organization》從現象一路寫到操作框架，中間解釋機制的那一段沒有跳過，證據規模也是本篇最大的一本。概念本身的整理在 <a href="/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感</a>，這裡處理的是要不要讀這本書。起點是一個反直覺的研究結果：她研究醫院團隊時預期表現好的團隊犯錯較少，資料卻顯示表現好的團隊回報的錯誤更多。追下去才發現差別出在回報率這一層，犯錯率其實相當——好團隊敢講。心理安全感這個概念與後續三十年的研究從這裡長出來。</p>
<p>書的操作價值在於把心理安全感從一種氛圍變成可以做的事。框架有三步：把工作定調成學習問題而非執行問題、承認自己會犯錯、主動示範提問。每一步都有語言範例與失敗案例，包括領導者宣稱歡迎壞消息但實際反應相反時會發生什麼。</p>
<p>需要先知道的邊界是心理安全感並非降低標準。書中把心理安全感與績效標準當成兩個獨立的軸，並指出兩者都高才是學習區、安全感高而標準低是舒適區。這個區分在導入時最容易被誤讀成「對人要溫和」。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是大規模實證加上跨組織案例，強度足以支持組織層級的改變。時效上，書中案例的產業背景橫跨醫療、航空、製造與科技業；心理安全感與績效標準兩軸的論證建立在人際風險的感知上，不依賴工作場所的形式。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，書中的介入手段——把工作定調成學習問題、當場承認自己會犯錯、主動示範提問——多數發生在同步的面對面場合，靠的是別人看得見領導者的即時反應。非同步為主的團隊要先找到對應的載體（公開的決策紀錄、留在文件上的提問、對壞消息的第一則回覆），那個轉換書裡沒有給，換算的方向見 <a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>。讀得出價值的前提幾乎沒有，任何位置都讀得出東西——只對自己產出負責的人讀它，讀出來的是「原來我不敢講不是我的問題」；帶人的人讀它，學到的是自己做了哪些動作，團隊才不再把壞消息講上來。</p>
<p>同作者的另外兩本各補一個面向，與這本承擔同一個角色而非獨立選項。《Teaming》處理跨團隊、跨專業的臨時協作怎麼學習，適合矩陣式組織或跨部門專案多的環境，目前無中譯本。《Right Kind of Wrong》把失敗分成簡單失敗、複雜失敗、智慧型失敗三類，並主張只有第三類值得鼓勵——這對把「快速失敗」當成免責聲明的團隊是直接的校正。兩本的證據來源與起點書同一組（大規模實證加跨組織案例），因此不另外判定；處境上，《Teaming》預設協作對象會換人，《Right Kind of Wrong》不預設任何組織形態。讀得出價值的前提是先讀過起點書那本——它們補的是面向，不是入口。</p>
<ul>
<li><a href="https://www.amazon.com/Fearless-Organization-Psychological-Workplace-Innovation/dp/1119477247">Amazon（The Fearless Organization）</a></li>
<li><a href="https://www.books.com.tw/products/0010952358">博客來（心理安全感的力量：別讓沉默扼殺了你和團隊的未來）</a></li>
<li><a href="https://www.amazon.com/Teaming-Organizations-Innovate-Compete-Knowledge/dp/078797093X">Amazon（Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy）</a></li>
<li><a href="https://www.amazon.com/Right-Kind-Wrong-Science-Failing/dp/1982195061">Amazon（Right Kind of Wrong: The Science of Failing Well）</a></li>
<li><a href="https://www.books.com.tw/products/0010985600">博客來（正確犯錯：哈佛學者揭開成長心態的關鍵）</a></li>
</ul>
<h2 id="想知道為什麼改善措施總是失效時讀-argyris">想知道為什麼改善措施總是失效時讀 Argyris</h2>
<p>Chris Argyris 的研究方法是逐字記錄組織裡的真實對話再逐句分析，因此是這個主題裡證據粒度最細的一位。貢獻集中在兩組概念。第一組是信奉理論與使用理論的落差：一個人宣稱相信的原則，與他的行為顯示他實際依循的原則經常不同，而本人通常看不見這個落差。第二組是組織防衛慣例：組織會發展出一套機制迴避尷尬與威脅，接著把「這套機制存在」本身也變成不可討論的話題，於是防衛無法被檢討。</p>
<p>這組概念解釋了為什麼許多文化改善措施會失效——措施本身成為新的表演場合，而指出「這是表演」變成新的不可討論話題。Edmondson 描述現象並給出做法，Argyris 解釋做法為什麼會被組織消化掉。</p>
<p>那篇 HBR 文章〈Teaching Smart People How to Learn〉是最經濟的入口，十幾頁，主張聰明人特別不擅長學習——因為他們很少失敗、沒有練習過面對失敗，一旦失敗就把責任外推。這個論點描述的處境在高學歷、高能力的工程團隊上有明確對應。</p>
<p>證據來源是跨客戶的顧問經驗，形式特別的地方在方法：長期的組織介入研究加上逐字對話分析，因此細節極具體，但樣本集中在少數顧問公司與大型企業。時效上，案例場景是 1980 年代的管理顧問與董事會，職稱與會議形式已經不同；信奉理論與使用理論的落差建立在人對自我形象的維護上，不依賴那個場景。文字的概念密度高、案例冗長，《Overcoming Organizational Defenses》是書的形式，但多數人從那篇文章得到的已經接近全書。兩者目前都沒有中譯本。讀得出價值的前提是：親身推動過一次無疾而終的改善——沒有這個對照時，防衛慣例會讀成對組織的譏諷。</p>
<ul>
<li><a href="https://hbr.org/1991/05/teaching-smart-people-how-to-learn">HBR（Teaching Smart People How to Learn）</a></li>
<li><a href="https://www.amazon.com/Overcoming-Organizational-Defenses-Facilitating-Learning/dp/0205123384">Amazon（Overcoming Organizational Defenses: Facilitating Organizational Learning）</a></li>
</ul>
<h2 id="程式碼審查滑向人身攻擊的起源在溫伯格-1971-年的the-psychology-of-computer-programming">程式碼審查滑向人身攻擊的起源在溫伯格 1971 年的《The Psychology of Computer Programming》</h2>
<p>這本書是最早把寫程式當成人類行為來研究的著作。書中的無私程式設計（egoless programming）——把程式碼與自我認同分開，才能坦然接受別人檢視——是今天 code review 文化的思想源頭。</p>
<p>現在讀它的價值集中在觀念層。25 週年紀念版的做法是保留原文不動、只在旁邊加註解評論自己當年錯在哪——作者認為自己的錯誤是讀者最能學到東西的部分。</p>
<p>證據來源是單一路徑的個人經驗（作者在 IBM 與 NASA 水星計畫的現場觀察）加上早期的受控實驗，樣本小、方法以現在的標準看相當鬆散。時效上，技術背景（主機、打卡、批次作業）已經完全不同，涉及工作流程的章節無法直接套用；程式設計師如何看待自己的產出、審查為什麼會滑向人身攻擊這兩條論證建立在自我認同與產出的連結上，不依賴技術形式。收過一次讓自己不舒服的 code review，是讀它的前提。繁體中文版目前未見，簡體中文版有《程序开发心理学》等譯名。</p>
<ul>
<li><a href="https://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420">Amazon（The Psychology of Computer Programming: Silver Anniversary Edition）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這個主題的三本按解釋深度排：現象與操作框架（Edmondson）、機制解釋（Argyris）、軟體業內部的起源（溫伯格 1971）。三者處理沉默的不同層次，任何一本都不能替代另外兩本。</p>
<p>企業文化的書是商管書市最擁擠的區塊，多數落在兩個位置：宣稱某家公司文化很成功的個案敘事，以及把文化拆成價值觀清單的操作手冊。前者無法回答「這在我的組織也成立嗎」，後者跳過了價值觀為什麼會被組織消化掉這一層——要區分，看它處不處理「宣告的價值觀與實際行為不同」這個落差，沒處理的停在第一層。</p>
<p>Google 的 Project Aristotle 常被拿來當心理安全感的佐證，它的一手資料是公開文件而非書籍，因此不列進書單。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>理解機制之後，落到單次對話的執行走 <a href="../influence-conversation/">困難對話與無權限影響力</a>——那裡處理的是主管盯著人問「到底行不行」的那三十秒。</p>
<p>沉默在事故現場的具體形式（明知有異狀卻沒有升級）走 <a href="../incident-blame/">事故、歸因與無指責檢討</a>。沉默在承諾現場的具體形式（明知做不完還是點頭）走 <a href="../estimation-decision/">估算、承諾與決策偏誤</a>。</p>
<p>人留不留得住是另一組問題，走 <a href="../retention-motivation/">留任、動機與工作環境</a>。</p>
<p>安全感夠了而討論仍然收斂不了，缺的是流程而非氣氛，走 <a href="../meeting-facilitation/">會議引導與群體決策</a>。兩者的先後不能顛倒——講真話會被記上一筆時，再好的會議格式也只會收到安全的答案。</p>
]]></content:encoded></item></channel></rss>