這是我在 Oplink 時的內部文件推廣訓練，幾年之後發現這份的想法還是很有用，重新整理（屏蔽部分資料）後，發佈出來。 Date: 2014/07/11

1. Wiki in Teamroom
Connected Mind
1
Rick Hwang
2014/07/11, v1.01
2019/05/26 Publish

2. Agenda
• Why Wiki in Teamroom
• CRUD Wiki in Teamroom
• Best Practice, and Practice
• Connected Mind
2

3. WHY WIKI IN TEAMROOM
3

4. Problem
• 有太多淺規則, 散落在各地: email, svn, source code, issue, skype 對話中,
腦袋裡, 各單位口耳相傳的傳說, 隨著時間的改變, 都有不一樣的結果;
• 東西的專有名稱也一大堆 (Basic Free Service, Standard, ?), 加上跨單位,
跨時間, 其背後造成的溝通成本, 是很難估量的.
• 無法掌握的淺規則
– RD 可以查 source code, 知道邏輯, 但無法得到全貌
– QA 需要額外花很多時間才能知道功能全貌, 測試沒有效率
• Sales/FAE/TS 知道的, 與 RD/QA 落差甚大, 或者一無所知.
• 產品角度來看, 看不到產品全貌與範圍, 時間越久, 露洞越多,風險越大
• 缺乏一致的整合介面, Diff 文件不容易
4

5. Example 1
5

6. 期望 …
6

7. Example: 如何Review更新的Spec
• 看 ChangeLog
• 一頁一頁對
• 根據 ChangeLog 描述, 比對差異
• 圖檔?
7

8. Goal
• 減少溝通鴻溝, 提升工作效率以及產出品質
• 一致性, 建立有價值, 且具公信力的文件
• 提升工作效率
• 知識分享與累積
• Member 有良好的互動, 默契, 相互學習與成長
• 連結與累積的資訊, 變成知識, 智慧, 資產, 刺激創新
• 新人教育訓練, 培育人才, 經驗傳承
• 總之 ….
8

9. CRUD WIKI IN TEAMROOM
Create, Read, Update, Delete …
9

10. Find Activity
10

11. Search
11

12. Read Wiki - Watch and History
12
URL: http://teamroom.oplink.com/projects/dragon/wiki/Phase_10_Design_Document

13. Read Wiki - Wiki Notification
1. Add as Watcher, you will receive notification if Wiki is changed:
13

14. Read Wiki - Diff
1. Highlight diff in Color
1. Removed
2. Added
14
http://teamroom.oplink.com/projects/dragon/wiki/App_Error_Code/diff/9

15. Read Wiki - Diff
15
http://teamroom.oplink.com/projects/dragon/wiki/Phase_10_Summary/diff?ver
sion=28&version_from=27&commit=View+differences

16. Edit Wiki - Syntax
1. Basic Wiki Syntax
2. Wiki Syntax Detail
3. Redmine Wiki Tips
4. Write a Readable Wiki Document
16

17. Wiki Syntax
1. Text formatting
2. Text format toolbar
3. Preview
17

18. Link Wiki to Any Issues / Wiki
1. Syntax: [[WIKI_TITLE]]
2. Cross project : [[PROJECT_ID:WIKI_TITLE]]
– Project ID (Case-sensitive)
• Dragon: dragon
• Lobby: redmine
• Webstore: webstore
• SpaceD: spaced
• SQA: sqa
18

19. EXERCISE… (5M)
19
http://teamroom.oplink.com/projects/redmine/wiki/Welcome_to_Teamroom

20. BEST PRACTICE
20

21. 寫文件的原則
• 釐清閱讀對象
• 文章形式
– 精準的標題
– 清楚的結構: Template
• 定期重新組織 (Refactoring) – 很重要
• 減法哲學
21

22. 釐清閱讀對象
Type Marketing Developer QA DevOps FAE Sales
Product Spec V V V V V
Device Spec V V V V V
Design Document V V
Deployment Document V V V
Test Spec V V
Release Notes V V V V V
22

23. 文章標題
• 代號: IPC1200, OPU2120
• 專有名詞: CDA, VIDEO_ABILITY_INFO
• 特定功能/集合: System Scheduling,
Connected APIs, IDEAS Command Index, Phase
10 Summary
• 描述 / 問答型
23

24. 文章架構的原則
• 整理過的資訊
– 整理, 組織過的
• 頭尾對應
• 連結相關文章, 引用文章
– Spec, Design
– Scenario
24

25. Template
• Design
– Project Phase Template
– Design Document Template
– Product Specifications Template
– Device Specifications Template
• Bug
– Bug Template - English
– Bug Template - CHT
– Bug Template - CHS
25
http://teamroom.oplink.com/projects/dragon/wiki/Wiki_Templates

26. 文章內容 - 表達形式
影片比圖好
圖比表好
表比文好
文比 Email 好
26

27. 定期重新組織文件結構
• Code 累積久了要重新調整 – Refactoring
• 文章久了也要重新調整
– 新舊糾結, 思考完整性, 維護性
– 好找
– 淘汰舊的
• Rename Subject
– Relink related Wiki
27

28. Wiki Structure in Teamroom
• Lobby
– Team Service, Training, Process
• Dragon
– Project Phases – Branch, time base view
– ODM – Branch
– Product Information – Trunk, totally view
– Software Component / Team – internal technical document
– Team Operation
28
http://teamroom.oplink.com/projects/dragon/wiki

29. CONNECTED MIND
29

30. 30
Photo Credit: Hugh MacLeod

31. 沒什麼是原創的
把知識連起來就是創意
31

32. 32
交差
文件不是用來
…

33. 33
溝通
文件最重要的目的
…

34. 34
溝通
是很大的成本
我不知道你不知道我知道你知道我的明白?

35. 35
釐清思緒
有效專注
連結知識
個人價值
文件的好處 … (對個
人)

36. 36
有效溝通
提升品質
經驗傳承
永續經營
文件的好處 … (對團隊/公
司)

37. You can't connect the dots looking forward;
you can only connect them looking
backwards.
37
-- Steve Jobs
你無法預先把點點滴滴串連起來
只有在未來回顧時
你才會明白那些點點滴滴是如何串在一起的

38. Next …
• Wiki Function
– Comment – Done
• Notification -- TBD
– Watcher List
– Custom Export (For other team)
– Template
– Associate to Category
• Upgrade redmine – improve performance
38

39. 39