組織信息軟件開發組織

Question

隨着時間的推移我們的信息化戰略已經得到處都是，我們希望有一個更清晰的政策，並讓每個人都在分享信息的同步更明確的方式。有些要注意的是，該組織有300多人，並且在全球多個國家。此外，我們有Sharepoint舒適的人員，舒適的合流人員等，因此這裏肯定會有一個「變化」因素。

以下是我們目前的問題以及我們正在考慮如何處理這些問題。我將非常樂意傾聽反饋意見，建議等

內容，我們今天：

1. 技術設計信息/架構文檔
2. 會議紀要，行動項目等
3. 項目計劃和路線圖
4. 組織業務管理信息 - 旅行，預算信息，人員信息等
5. 具有業務分析，需求等的項目頁面

下面是我們的一些主要問題：

數據應該去哪裏 - Confluence維客與共享點與內部網站 - 我們使用＃1 Confluence維客，＃2，＃3，＃5，但我們也使用＃1，＃3，＃4，＃5的共享點。我們正在設法弄清楚，我們是否應該將每個號碼都強制到一個特定的地方，以使事情保持一致。我們更多地使用Sharepoint文檔的目錄結構，並且我們正在使用confluence來構建更多特殊的可變內容。

陳舊的數據 - 這可能是一個組織文化的東西，但在某些時間點，數據只是變得陳舊，不再相關。什麼是確保舊數據不會產生大量的噪音，並保證最新的正確的數據是最新的，最好的方式。組織中是否應該有人對此負責，還是應該是隱含的「每個人的工作」。當人們離開，加入等時，這更成爲一個問題。 。

更積極使用 - 什麼是讓人們離開的電子郵件，並試圖阻止，並認爲最好的方式。「這會是對別人有用，讓我把它放在一個集中的地方，而不是在電子郵件鏈」 。 。

也，的好方法來改善組織的溝通和信息管理

Answer 1

信息混亂的一個基本根源是「沒有所有權」。

人們被分配到項目。項目結束（或被取消），人們繼續前進，文件仍然滯留，以收集「灰塵」，併成爲信息混亂。

這很難防止。 wiki與sharepoint並沒有解決混亂問題，它只是改變了用來積累混亂的技術基礎。

讓我們看看雜波

1. 技術設計信息/架構文檔。舊的不重要。目前有和無關的。維基。

   去年的陳舊設計信息已經過時了。

2. 會議紀要，行動項目等行動項目成爲某人在發展衝刺中積壓的一部分，或者，他們可能永遠不會完成。待辦事項是wiki項目。其他一切都是歷史，可能是有趣的，但通常不是。如果它沒有創建衝刺積壓項目，更新架構或解決開發問題，那麼會議可能是浪費時間。

3. 項目計劃和路線圖。衝刺積壓很重要 - 這是「計劃和路線圖」渴望成爲的。如果你必須用路線圖補充你的計劃，你可能應該放棄計劃，只使用Scrum，並保持積壓。

   最初的計劃是某人對項目開始時間的猜測，對當前的項目團隊來說並不是很有趣。

4. 組織業務MGMT信息 - （？「旅行」）旅行，預算信息，員工人數的信息等，這是高度結構化的東西（預算，組織）和非結構化的東西，一個奇怪的混合

   了多少歷史你需要？沒有？維基充其量。財務或人力資源系統是它所屬的地方。但是，在大型組織中，會計系統使用起來可能比較困難而且麻煩，所以我們創建了二級信息來源，如帶有過期預算編號的SharePoint頁面，因爲實際預算數字被埋在Oracle Financials內部。

5. 具有業務分析，需求等的項目頁面這是您的積壓。你的項目路線圖，你的要求和你的分析應該是一個單一的文件。在wiki中。

   歷史很少問題。在項目開始階段，有些人的要求是什麼概念並不重要。最終形成的要求演變得比任何歷史都要重要得多。這是維基材料。

「太舊了」是幾歲？ 我曾與擁有30年曆史的軟件的客戶合作。顯然，軟件是相關的，因爲它在生產中。

但是，文檔都是垃圾。該軟件一直保持。它充滿了變更控制記錄。由於變更控制文件可能非常普遍，因此要查看變更的適用位置的唯一方法是閱讀源代碼，並從中 - 讀取源代碼，反向設計當前狀態規範。

如果我們只能通過對源代碼進行逆向工程來了解30年前的應用程序，那麼就可以查看這張30年前的紙張。沒用的。

一旦完成維護，「原始」規範就被貶值了。

如何清理它？ 如果您創建維基頁面或SharePoint站點，則永遠擁有它。 當你離開時，你的替代品永遠擁有它。

每位經理都對其員工創建的每一條信息負全部責任。他們必須刪除東西。薄弱的解決方案是「歸檔」東西。這只是在沒有「D字」的情況下說「刪除」的禮貌方式。

清理必須是每個經理的持續責任。如果他們不記得它是什麼，或者他們爲什麼擁有它們，則應該要求（或「鼓勵」）刪除它。在過去的兩年中沒有訪問過的東西應該毫無疑問地歸檔。 10歲的一切都只是無關緊要的歷史。

這是痛苦的，它似乎並不是創造價值的工作。畢竟，我們在IT方面工作。我們的工作是「寫」軟件，而不是刪除它。除非被迫解僱威脅，否則沒有人會這樣做。

存儲成本相對較低。清理成本似乎更高。

如何停止電子郵件鏈？
拒絕參與。創建一個「打破連鎖」活動，重點是用維基更新（或共享點更新）取代電子郵件鏈。

確保您的wiki提供鏈接，並且編輯速度比電子郵件快。

你不能強迫人們放棄一個真正方便的解決方案（電子郵件）。你必須讓wiki更有價值，幾乎和電子郵件一樣方便。

增加維基上的值。棄用電子郵件鏈。拒絕回覆電子郵件鏈。拒絕接受通過電子郵件「做」行動項目。

Answer 2

可以使用Confluence維客用於存儲文檔作爲附着物和具有wiki的路徑中的任何其他的故事作爲工作在SharePoint中的文件路徑。

回覆：陳舊數據：有數據（包括個人和團隊）的所有權，並保證爲業主交付包括所有數據的維護。

至於「關電子郵件」，這是很難做到的，因爲你不能強迫人們去做這短短的積極監測所有電子郵件...但你可以嘗試與有關內容加入到維基度量一些成果。這種方式，人們會更容易想重新使用上的電子郵件已經完成的工作，以粘貼到維基滿足「配額」，而不是構成新鮮玩意兒。

公司和/或團隊使用這些方法具有某種程度的成功的所有3過去

Answer 3

有沒有理由不讓wiki維持文件？

另外，郵件服務器可能限制不允許在內部電子郵件附件是太苛刻，但要求人們把一切都需要通過電子郵件發送不止一次維基是相當不錯的實用。

Answer 4

高效的信息管理確實是一個非常難的問題。我們發現「越簡單越好」的原則可以創造奇蹟來解決它。

應該在哪裏去的數據 - 我們是維基做法大的信徒。實際上，我們使用Confluence來共享可能的每種類型的信息，除了真正大的二進制文件。對於這些，我們使用Dropbox。它的簡單性是絕對的殺手鐗。 （提示：您可以將它們與Dropbox in Confluence插件集成）

查找陳舊數據 - 在我們的定義，陳舊的數據是什麼，不更新或特定的時間內觀看。 Archiving Plugin of Confluence可以快速自動找到這些信息，然後將它們報告給作者和管理員，他們可能會更新它們（或刪除它們，請參閱下一項）。當然，信息永遠不會過期，但插件可以在標記相應頁面後跳過它們。

刪除陳舊的數據 - 我們對此非常積極。如果數據不再（高度）相關，請立即清理它現在！我們可以安全地遵循這種做法，因爲我們從未真正刪除數據。我們只是使用Archiving Plugin將過期數據移至隱藏的存檔空間。如果我們後來改變了主意，很容易在檔案中找到它，查看它甚至恢復它。

更活躍的用法 - 我們的規則：如果要求信息持久，請不要通過電子郵件發送。把它放到wiki頁面上。對於某些人來說，困難的事情是找到信息的最佳位置（哪個空間？在頁面層次結構中的哪個位置？）。不幸的是，組織嚴密的空間範圍是另一個大的效率分配器。大公司可能會考慮引入wiki gardener來解決這個問題。